Yeah, the PartyClassificationGroup would have many parents - that's how the book has it modeled. PartyType has a one-to-many relationship with the PartyClassification super type, so a PartyType could point to more than one PartyClassification subtype.
I'm starting to have a sense of deja-vu - like we've discussed this before in the past. I'll have to dig through my mail archives. Thanks for the clarification! -Adrian --- On Mon, 1/10/11, David E Jones <[email protected]> wrote: > Your understanding of the data model is not correct. > > The PartyClassification entity is just a join entity > between Party and PartyClassificationGroup. The entity > definition itself can help clarify this because it follows > the same pattern as join entities in general in OFBiz, ie > the fields are (the first 3 are pks): > > partyId* > partyClassificationGroupId* > fromDate* > thruDate > > This is the basic pattern for join entities. Other example > include PartyContent, ProductContent, ProductCategoryMember, > and dozens (hundreds?) of others. Any time two entities have > a many-to-many relationship a join entity is needed to go > between them. > > For PartyClassificationGroup note that it has a > "parentGroupId" field making the structure hierarchical > (like many other *Type and other entities that need a simple > hierarchy). > > In your example Hispanic would be a > PartyClassificationGroup that is a child of the US > Minorities group. Note that the current structure is a pure > hierarchy, ie it is not a graph, and each node can only have > a single parent. If you want a PartyClassificationGroup to > have multiple parents then you'll need another join entity > to model that many-to-many relationship (much like > ProductCategoryRollup). > > -David > > > On Jan 10, 2011, at 4:27 PM, Adrian Crum wrote: > > > I spent some time in Party Manager trying to make > sense of the Party Classification feature, and I can't seem > to make it do anything meaningful. Maybe I'm not > understanding something, so I'll provide an example and see > if anyone knows how to implement it in the current code. > > > > In table 2.3 of the Data Model Resource Book, there is > a party named Marc Martinez who has been classified as > Hispanic. I will use him for my example. > > > > In Party Manager I create a person named Marc Martinez > and I want to classify him as Hispanic. I would also like to > include the Hispanic classification in two classification > groups: US Minorities and Non-White. I go to the > Classifications tab - where I can create classification > groups from a list of pre-defined group types. I choose the > Minority type, type "US Minorities" in the Description > field, and save the group. I want to add the Hispanic > classification to this group, but I don't see any way to add > classifications. I go to Marc's profile page and try to > assign him a classification, but I can only assign him to a > classification group. If I assign him to the "US Minorities" > group that still doesn't classify him as Hispanic. > > > > As far as I can tell, Party Classification doesn't > work. > > > > Any ideas? > > > > -Adrian > > > > > > --- On Mon, 1/3/11, Adrian Crum <[email protected]> > wrote: > >> 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 <[email protected]> > >> 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 <[email protected]> > >>> 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 > <[email protected]> > >>>>> 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<[email protected]> > >>>>> > >>>>>>> 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<[email protected]> > >>>>>>>>> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> > > > > > > > >
