Hi, I think it will be good for Tryton to try to get closer to the Active Record pattern [1].
So here are some steps to achieve this goal: cursor, user and context ------------------------ They should be removed from the function call and be shared across the code by thread. I propose to create an object trytond.transaction that will be handle those thread-local data [2]. It will be filled by the trytond.protocols.dispatcher for each remote call. It should also be able to save current data in a stack and restore it later because in some part of the code we need to perform some actions with the rights of an other user or execute some database queries in a different transaction. It should also ensure that the stack have been "poped" before the end of the transaction. To be able to fill the transaction object with the context, the RPC signature call should be changed to know which argument is the context. Pool ---- The pool should be retrieve from the transaction object instead of beeing liked to the models. This will ensure that the database on which the cursor is connected is the same then the one define for the Pool. And it will also allow to have fields named "pool". Model ----- We should stop working with Model instance in the Pool but use only classes. So the current function like "create", "write", "search", "browse" etc. that take almost all ids as argument should become classmethods and browse will return an instance of the Model instead of the BrowseRecord. Of course, we should keep the cache management from the BrowseRecord and the way we read data for many ids at once to keep good performance. This will allow to change the setter, getter function that will work on the "BrowseRecord" (that will be a Model instance) instead of working on ids. Button function will also become classmethods. And a new function will be available on Model instance named "store" that will perform the write of changes in the database. The __init__ way of changing Model will be replace by metaclass programming [3]. Extension --------- This is the part that I don't see well how we could make it more pythonic. For now, the mechanism is: - we store Model instances in a dict (Pool) by their name - if there is already a Model class with the same name, we make the new one inherit (in the python way) from the old one. And replace the old by the new one. So Tryton extension is based on "on the fly" inheritage. The pool constructs a new object from the module installed for a database. This can be viewed like decorators or monkey patching [4]. I don't know yet which method will be the best one. But I'm pretty sure that we must stop faking instanciation of the Models (in fact it register it in the Pool) and using directly the method Pool.register(klass, ...) Planning -------- All those changes can not be done of course for the 1.6 release but I think it is possible for 1.8. Each steps describe here can be done one by one and keeping the software working. But of course it will require some modifications for the modules. But I think if we use well-know patterns like Active Record, it will reduce the learning curve of programming in Tryton. Others ------ I often see people asking (on OpenERP) why not using SQLAchemy [5] especially for the pythonic syntax of query. I think we should keep the current domain syntax that uses only simple objects (list, string, tuple) because it allow to expose it to the RPC protocols without too much difficulty because all common languages have this simple objects. But it could be extended to allow aggregation, field to field operations etc. So comments are welcome, especially on the "Extension" part. I will write a blue print shortly. [1] http://en.wikipedia.org/wiki/Active_record [2] http://docs.python.org/library/threading.html#threading.local [3] http://docs.python.org/reference/datamodel.html#customizing-class-creation [4] http://en.wikipedia.org/wiki/Monkey_patch [5] http://www.sqlalchemy.org/ -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgp5X0giKbMJ4.pgp
Description: PGP signature
