These ideas are really good and will make Tryton more pythonic.
Regarding Model:
If metaclass programming is used and each record becomes an instance of the
class representing the model, then the methods of the class becomes
methods/functions/properties acting on individual instances (or records) and
not the object as a whole.
- So how is the extension of modules planned ?
For example:
a current pool.get(object).write(...) can no longer exist but a write will
be method of the instance.
So if productcategory1 = ProductCategory(<values>) then the write method
will be an instance method therefore productcategory1.write(<values>)
- Can we use args/kwargs based initiation
I think the metaclass programming should give us the advantage of creating
instance objects from kwargs. For example new_category =
ProductCategory(name="Computers", code="COMP")
- Can inheritance of models also be pythonic?
Instead of using _inherit = '' can we directly use python inheritance. For
example, if we have to extend product category then:
from trytond.modules.product.category import ProductCategory
class NewProductCategory(ProductCategory):
def get_full_name(self):
return self.parent_name + "/" + self.name
Sharoon Thomas
Business Analyst & ERP Consultant
Open Labs Business Solutions
http://openlabs.co.in
On Mon, Mar 22, 2010 at 3:15 PM, Cédric Krier <[email protected]> wrote:
> Hi,
>
> I think it will be good for TrytoI n 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/
>
--
[email protected] mailing list
To unsubscribe from this group, send email to
tryton-dev+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
