| Thread Previous • Date Previous • Date Next • Thread Next |
Le 08/03/11 13:24, Raphaël Valyi a écrit :
I've thought extensively to the topic and here is the progressive migration path I propose toward a better performance (this can also be a generic custom attributes pattern for OpenERP that's why I post it th the framework list too): 1) move the magento attributes in a different table and define a new object like "product.extended" which would inherit from product.product. Hence loading Magento extra attributes will only happen when browsing that extended object via a dedicated menu/wizard. Regular OpenERP browse/read of "product.product" would then be as fast as usual.
This begs the question of the actual use of the normal product views once the magento connector is installed... Do you expect the users to need the custom Magento attributes very often? Or would the normal product view be sufficient in most cases, and having the "magento extra" view available as a link on the normal view would be enough?
2) I don't think there is a real need for a full blown EAV pattern (or at least I think it's not our job to take care of doing that in an ecommerce connector): to gain extra perf, we could keep all the optional Magento defined fields and make them "fields.function". Instead of all having their custom columns, they could rather pull/push their value form/into a a JSON ( http://www.json.org/ ) text element inside a single field of "product.extended" (could also be XML but I tend to find it more bloated). Thus we would have only ~1 extra text field no matter how many extra custom attributes, now matter how sparse they are. I think those sparse optional attribute don't deserve to be SQL, it's just a custom data bag where we when to store custom attributes in a formatted manner. The advantage of doing 1) too in the scenario woudl be we avoid hitting always that JSON field + in/out costly methods when we don't need to; that is however is still open question fro me.
I'm not 100% comfortable with this approach, but I guess it makes sense. Things to double-check: - are you sure you will never need these custom properties in any SQL query? never ever? - what kind of data types will you store? no relationships? nothing that needs to be validated or have referential integrity?
On a side note: you could use a custom fields.text column for storing this bag, with _prefetch set to False, in order to avoid having it prefetched with other fields (in relation with the issue discussed in https://bugs.launchpad.net/openobject-server/+bug/731156). Pretty much like a fields.binary.
| Thread Previous • Date Previous • Date Next • Thread Next |
