Quick note: as per our earlier discussion keep in mind that PartyType in OFBiz has nothing/zippo/zero to do with what is referred to as "party type" in the book.
-David On Jan 10, 2011, at 8:55 PM, Adrian Crum wrote: > 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > >
