Every single *Type entity in OFBiz is a deviation from the book (ie the *Type entities are an OFBiz pattern to avoid redundant entities and keep track of entity extensions like the Party -> PartyGroup,Person thingy), as are dozens of other entities and hundreds of fields. That book is valuable for general concepts and patterns, and is not an actual data model to be used as-is.
-David On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: > I don't think I'm generalizing anything. The book is pretty specific and > clear: Party Classification is an intersection entity that sets up a > many-to-many relationship between the Party entity and the Party Type entity. > > I understand OFBiz deviates from the book here and there, and if this is one > of those cases, then I'll ask again: Why was it done that way? > > I'm trying to make sense of the OFBiz Party Classification model, and so far > it doesn't make sense. The way it is set up, I can't give a party a > classification without first creating a classification group, assign a > classification type to it, and then assign the party to the classification > group using party classification. > > In the book it's much simpler - I just assign a party type to a party using a > party classification. Classification groups are Party Classification > sub-types and they aren't necessary unless I want to group things a certain > way. > > -Adrian > > --- On Mon, 1/3/11, David E Jones <d...@me.com> wrote: >> I think you may be taking the specific term "type" and >> generalizing it. Consider that *Type entities in OFBiz mean >> something very specific, and it is different from the more >> general use of the term in the book. >> >> -David >> >> >> On Jan 3, 2011, at 3:24 PM, Adrian Crum wrote: >> >>> That's not what the book shows. There is a simple >> relationship: >>> >>> Party -> PartyClassification -> PartyType >>> >>> If you want to group classifications, give them >> parent/child relationships, etc then you do it with >> PartyType, not PartyClassification. Look at table 2.3 on >> page 32. >>> >>> -Adrian >>> >>> --- On Mon, 1/3/11, BJ Freeman <bjf...@free-man.net> >> wrote: >>>> how about a pattern of parent child >>>> for PartyClassification of supertype >>>> and the sub types then use a >> table for the >>>> attributess of the subtype. >>>> this would allow walking the parnent child >> relationships. >>>> PartyClassification >>>> >> --->organizationClassification---->minorityClassification >>>> >> >>>> >>>> ---->industryclassification >>>> >>>> ========================= >>>> BJ Freeman >>>> Strategic Power Office with Supplier Automation >>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>> Specialtymarket.com <http://www.specialtymarket.com/> >>>> Systems Integrator-- Glad to Assist >>>> >>>> Chat Y! messenger: bjfr33man >>>> >>>> >>>> Adrian Crum sent the following on 1/3/2011 2:46 >> PM: >>>>> PartyClassificationGroup should have a >> one-to-one >>>> relationship with an entity called >>>> PartyClassificationGroupType. >>>>> >>>>> -Adrian >>>>> >>>>> --- On Mon, 1/3/11, BJ Freeman<bjf...@free-man.net> >> >>>> wrote: >>>>>> so the Party Classification Group >>>>>> table would have a one to one with >>>>>> Classification Types >>>>>> or vica versa. >>>>>> >>>>>> >>>>>> ========================= >>>>>> BJ Freeman >>>>>> Strategic Power Office with Supplier >> Automation >>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>> Systems Integrator-- Glad to Assist >>>>>> >>>>>> Chat Y! messenger: bjfr33man >>>>>> >>>>>> >>>>>> Adrian Crum sent the following on 1/3/2011 >> 1:41 >>>> PM: >>>>>>> Looking into this more, The Data >> Model >>>> Resource Book >>>>>> mentions classification groups - but I >> believe the >>>> author >>>>>> meant that Party Types could be grouped >> together >>>> in >>>>>> classification groups. In other words, >> the >>>> classification >>>>>> groups are defined by the data contained >> in the >>>> Party Type >>>>>> table - not in a separate "Party >> Classification >>>> Group" >>>>>> table. There is nothing stopping us from >> having a >>>> Party >>>>>> Classification Group table, but it should >> group >>>> Party Types, >>>>>> not "Classification Types." >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> --- On Mon, 1/3/11, Adrian Crum<adrian.c...@yahoo.com> >>>>>> wrote: >>>>>>>> Looking at The Data Model >> Resource >>>>>>>> Book and the way OFBiz models >> Party >>>>>> Classification, it >>>>>>>> appears to me OFBiz models it >> wrong. >>>>>>>> >>>>>>>> According to the book, the Party >>>> Classification >>>>>> entity ties >>>>>>>> a Party to a Party Type with a >> from and >>>> thru >>>>>> date. >>>>>>>> >>>>>>>> In OFBiz, the Party Classification >> entity >>>> ties a >>>>>> Party to a >>>>>>>> Party Classification Group with a >> from and >>>> thru >>>>>> date. The >>>>>>>> Party Type is tied directly to >> Party with >>>> no from >>>>>> and thru >>>>>>>> date. >>>>>>>> >>>>>>>> Was that intentional? Why was it >> done that >>>> way? >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > >
