← Back to team overview

openerp-expert-framework team mailing list archive

Re: a plan for dealing with the many (Magento) custom EAV product attributes

 

On Tue, Mar 15, 2011 at 11:47 AM, Olivier Dony <odo@xxxxxxxxxxx> wrote:

> 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?


Yes exactly, this is already the case today: Magento attributes are only
available via the Magento specialized menu (pass the attribute set in the
context, it's required to build the view accordingly to the attribute_set)
or via a wizard from the standard from view that Sebastien added some 2
weeks ago.

>
>
>  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?
>

Absolutely, that's the trade-off and that's why I only want to limit this to
the optional attributes. Notice that Magento has a lot of flexibility here,
but it very very slow in its SQL join over its EAV schema anyway. So there
is no free beer. But for me it's the best trade-off.


> - what kind of data types will you store? no relationships? nothing that
> needs to be validated or have referential integrity?
>

All kind of fields (not binary though and possible not m2m at least in a
first stage). I think we can keep the relationships unchanged, it's just
about making those fields fields.function and and providing them a func_inv
that would properly write the JSON of their value in the blob.


> 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.
>

Yes, I agree with the idea to store the JSON in that field. In that case, we
could do it using a single table.

@xrg "Which reminds me of the "struct" field, which I wrote, and then
stashed away
because thought "who needs it, anyway?""

Interesting. However, In that particular case, I think it that we can have
easy field edition only if the clients know the fields already. I don't want
to re-implement a client widget, especially that the GTK client is still
somewhat required and that only OpenERP SA manage its release policy. So I
think it would be preferable to just keep the fields.foo nature of the
original Magento fields in order to keep the exactly same client widgets +
domain with no headache. I'm not sure your solution would allow that.
Thoughts?


Raphaël Valyi
Founder and consultant
+55 21 3010 9965
www.akretion.com



Regards.

References