Understood. If we wanted to create entities to avoid the sub-types mentioned in the book (Organization Classification, Person Classisfication, etc) then I think we could have done that in a simpler way and still keep the book's model:
PartyClassificationGroupType ---------------------------- *groupTypeId description parentGroupTypeId PartyClassificationGroup ------------------------ *groupTypeId *partyTypeId Anyways, I have come up with a workaround. I'll just use the existing PartyClassificationGroup the way the book uses PartyType. -Adrian --- On Mon, 1/3/11, David E Jones <d...@me.com> wrote: > 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 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > >
