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! _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
