Hi Phil, On 19 Aug 2010, at 15:27, Phillip Heller wrote:
> Sharoon et al, > > One thing I had talked with Cédric about recently was a similar EAV concept, > for the purposes of tracking individual instances of a product. > > So, perhaps there would be a ProductInstance model, which "realizes" all of > the attributes associated with a product. > > A good example would be a manufacturer assigned serial number, or a Hardware > MAC address. Perhaps you order 10 Apple Macbooks for resale. In Tryton, the > "Macbook" product would have attributes including "Serial Number", "MAC", > etc. These would have AttributeOptions that would include "not null", so on > instantiation of a ProductInstance for each of these 10 Macbooks, these > attributes would need to be populated. Well i dont think that this EAV model would fit this purpose of a serial number. However, in other terms this could be generalised. let me stick to the example of mac book. Attributes could be: Screen Size Weight Processor Memory HDD etc. which remain constant for a product. having a different serial number, I am not sure is an attribute issue. I think its more of an inventory tracking issue ? > > Another question is how will you accommodate for relational attribute values > (o2m, m2o, m2m)? Entity(Eg. Product) <--Function(O2M)--> AttributeValue > > Thoughts of how these things might fit into this EAV pattern? > > --phil > > On Aug 19, 2010, at 7:29 AM, Sharoon Thomas wrote: > >> Hi Cedk, >> >> On 19 Aug 2010, at 12:18, Cédric Krier wrote: >> >>> On 18/08/10 18:25 +0200, Mathias Behrle wrote: >>>> * Betr.: " [tryton-dev] Product Attributes EAV model" (Wed, 18 Aug 2010 >>>> 13:46:55 +0100): >>>> >>>>> Hello All, >>>>> >>>>> We have built a POC for the EAV [1] model of storing product attibutes. >>>>> Quite >>>>> often we have to add extra fields to product depending on specific >>>>> customer >>>>> installations. Like color, manufacturer etc. >>>>> >>>>> This is a general approach to the problem by having a relationship between >>>>> products and attributes just like contact mechanisms of party. >>>>> >>>>> I request your comments and code review on the same. >>>>> >>>>> [1] http://en.wikipedia.org/wiki/Entity-attribute-value_model >>>> >>>> Very interesting concept, thanks a lot! >>>> >>>> For an even more generic generic way, I would even favor to put models >>>> >>>> ProductAttributes -> Attribute >>>> ProductAttributeOptions -> AttributeOption >>>> >>>> in a separate module attribute (thus they could be (re)used on a number of >>>> different objects where the same concept could be required (like party in >>>> [1])) >>>> >>>> and to do only the product specific implementation in module >>>> product_attribute >>>> containing models >>> >>> But what will be the advantage to have all atributes in one table? >>> Because you will have the same attribute available for any Model, I find it >>> strange. >>> >> Not exactly: >> >> Attribute >> ====== >> model: - The model for which the attribute is valid for >> name: - Name of attribute >> type: - Data type of the attribute >> options: o2m Attribute option >> >> AttributeOption >> ============ >> attribute m2o attribute >> values - the option value >> >> AttributeValue >> =========== >> >> entity: reference field (model, id) >> attribute: m2o Attribute >> value: value of attribute >> >> So infact the attribute is domain[ed] on the model. So only relevant >> attributes should get displayed in the corresponding object. >> >> Hope it sounds ok ? >> >> Thanks, > Thanks, Sharoon -- [email protected] mailing list
