openerp-expert-framework team mailing list archive

["P. Christeas" <p_christ@xxxxxx>]

On Friday 20 May 2011, sebastien beau wrote:
> Hi xrg,
> 
> What you did is complementary of what I do.
> Let's explain. In magento we can have a lot of different attribut per kind
> of product. For example if I sold camera , I will have 'number of pixel',
> 'zoom','screen size'.
> As I don't want to store all of the value in 3 new column in my sql table I
> will use a json field let's call him 'magerp'.
> 
> If I use you patch I will acces to the value of the field doing
> product = self.browse(cr, uid, id, context=context)
> my_number_of_pixel_is = product.magerp['number_of_pixel']
>...
>  Example:
> product = self.browse(cr, uid, id, context=context)
> my_number_of_pixel_is = product.magerp.number_of_pixel
> It's very usefull for m2m, o2m, mo2 fields
> so you can do for example : product.magerp.color.name

I see, thanks for the explanation.

For the history, my idea came when I realized we were storing composite fields 
as repr()'ed text (not even the 'serialized' type) and then losing type 
information. So far, there has been no implementation that uses the 'struct' 
field, that's why I never committed it even into my experimental branch.

I generally try to produce minimal patches, that touch nothing but the area 
they are trying to improve. Reading the code of yours that adds an extra 
osv.osv layer of functions made me feel a bit uncomfortable (as a matter of 
principle, not suggesting that your code doesn't work).

We've also had this problem with computed records in base_calendar's recurring 
entries. They are whole records that we tried to make appear as real ones, but 
share their id +subid with one existing. Instead of fixing the client (and API) 
to support such a case, we implemented non-numeric ids, that eventually had us 
patch all other places of the code (and produce a wide range of bugs).

What I believe (and that's only my contribution to the discussion) is that 
we'd better extend the API (and client support) for composite fields, rather 
than try to map them to something that was not designed for that reason. This 
will be in a long-term horizon, obviously.

Said that, I prefer your getattr syntax, rather than the getitem one (dot 
notation vs dict notation). That would be easy to have in any case.



-- 
Say NO to spam and viruses. Stop using Microsoft Windows!