Party Classification Data Modeling
Locked
12
12
Party Classification Data Modeling
 
|
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 |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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 > > > > > > > |
Re: Party Classification Data Modeling
|
|
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<[hidden email]> 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 >> >> >> >> >> >> >> > > > > |
Re: Party Classification Data Modeling
|
|
on page 30 the organization classification would be group with subtypes
classifications minority, industry, size. now industry and zize would reqire a value. the sub types could be enumerations entity. ========================= 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 BJ Freeman sent the following on 1/3/2011 2:36 PM: > 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<[hidden email]> 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 >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > |
Re: Party Classification Data Modeling
|
|
In reply to this post by BJ Freeman
PartyClassificationGroup should have a one-to-one relationship with an entity called PartyClassificationGroupType.
-Adrian --- On Mon, 1/3/11, BJ Freeman <[hidden email]> 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<[hidden email]> > 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 > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > |
Re: Party Classification Data Modeling
|
|
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<[hidden email]> 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<[hidden email]> >> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> > > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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<[hidden email]> > 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<[hidden email]> > >> 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 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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<[hidden email]> >> 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<[hidden email]> >>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >> >> > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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 <[hidden email]> > 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<[hidden email]> > > >> 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<[hidden email]> > >>>> 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 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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 <[hidden email]> >> 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<[hidden email]> >> >>>> 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<[hidden email]> >>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> > >> 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<[hidden email]> > >> > >>>> 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<[hidden email]> > >>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> > > 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 <[hidden email]> > > >> 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<[hidden email]> > > >> > > >>>> 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<[hidden email]> > > >>>>>> 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 > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > > > > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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 <[hidden email]> >> 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 <[hidden email]> >>> 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 <[hidden email]> >>>>> 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<[hidden email]> >>>>> >>>>>>> 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<[hidden email]> >>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> > >> 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 <[hidden email]> > >>> 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 > <[hidden email]> > >>>>> 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<[hidden email]> > >>>>> > >>>>>>> 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<[hidden email]> > >>>>>>>>> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> > > > > > > > > |
Re: Party Classification Data Modeling
|
|
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 <[hidden email]> 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 <[hidden email]> >> 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 <[hidden email]> >>>> 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 <[hidden email]> >>>>> 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 >> <[hidden email]> >>>>>>> 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<[hidden email]> >>>>>>> >>>>>>>>> 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<[hidden email]> >>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > > |
Re: Party Classification Data Modeling
|
|
In reply to this post by Adrian Crum-2
<PartyClassificationType description="Minority" hasTable="N"
parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> <PartyClassificationType description="Hispanic" hasTable="N" parentTypeId="MINORITY_CLASSIFICA" partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> Adrian Crum sent the following on 1/10/2011 4:27 PM: > 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 <[hidden email]> 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 <[hidden email]> >> 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 <[hidden email]> >>> 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 <[hidden email]> >>>>> 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<[hidden email]> >>>>> >>>>>>> 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<[hidden email]> >>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > > > > |
Re: Party Classification Data Modeling
|
|
And your point is? That doesn't assign Hispanic to a classification
group, it only makes Hispanic a child classification of the Minority Classification. At any rate, I have implemented the pattern I needed locally, and I have given up trying to make the case for an improved Party Classification data model. -Adrian On 9/4/2011 7:04 PM, BJ Freeman wrote: > <PartyClassificationType description="Minority" hasTable="N" > parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> > <PartyClassificationType description="Hispanic" hasTable="N" > parentTypeId="MINORITY_CLASSIFICA" > partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> > > > Adrian Crum sent the following on 1/10/2011 4:27 PM: >> 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<[hidden email]> 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<[hidden email]> >>> 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<[hidden email]> >>>> 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<[hidden email]> >>>>>> 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<[hidden email]> >>>>>>>> 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<[hidden email]> >>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> >> |
Re: Party Classification Data Modeling
|
|
Parent child is the same as grouping in my view.
it even gives you a hierarchy so if you point to Hispanic you can find it under Minorities. if you want to further define Hispanic, Like Castillian or Mexican they can be child of Hispanic Adrian Crum sent the following on 9/4/2011 11:10 AM: > And your point is? That doesn't assign Hispanic to a classification > group, it only makes Hispanic a child classification of the Minority > Classification. > > At any rate, I have implemented the pattern I needed locally, and I have > given up trying to make the case for an improved Party Classification > data model. > > -Adrian > > On 9/4/2011 7:04 PM, BJ Freeman wrote: >> <PartyClassificationType description="Minority" hasTable="N" >> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >> <PartyClassificationType description="Hispanic" hasTable="N" >> parentTypeId="MINORITY_CLASSIFICA" >> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >> >> >> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>> 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<[hidden email]> 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<[hidden email]> >>>> 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<[hidden email]> >>>>> 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<[hidden email]> >>>>>>> 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<[hidden email]> >>>>>>>>> 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<[hidden email]> >>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> > |
Re: Party Classification Data Modeling
|
|
No, I want Hispanic to be a member of an arbitrary number of groups.
-Adrian On 9/4/2011 7:34 PM, BJ Freeman wrote: > Parent child is the same as grouping in my view. > it even gives you a hierarchy > so if you point to Hispanic you can find it under Minorities. > if you want to further define Hispanic, Like Castillian or Mexican they > can be child of Hispanic > > Adrian Crum sent the following on 9/4/2011 11:10 AM: >> And your point is? That doesn't assign Hispanic to a classification >> group, it only makes Hispanic a child classification of the Minority >> Classification. >> >> At any rate, I have implemented the pattern I needed locally, and I have >> given up trying to make the case for an improved Party Classification >> data model. >> >> -Adrian >> >> On 9/4/2011 7:04 PM, BJ Freeman wrote: >>> <PartyClassificationType description="Minority" hasTable="N" >>> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >>> <PartyClassificationType description="Hispanic" hasTable="N" >>> parentTypeId="MINORITY_CLASSIFICA" >>> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >>> >>> >>> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>>> 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<[hidden email]> 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<[hidden email]> >>>>> 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<[hidden email]> >>>>>> 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<[hidden email]> >>>>>>>> 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<[hidden email]> >>>>>>>>>> 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<[hidden email]> >>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> |
Re: Party Classification Data Modeling
|
|
Looks like I missed an important part of you thinking.
Adrian Crum sent the following on 9/4/2011 11:36 AM: > No, I want Hispanic to be a member of an arbitrary number of groups. > > -Adrian > > On 9/4/2011 7:34 PM, BJ Freeman wrote: >> Parent child is the same as grouping in my view. >> it even gives you a hierarchy >> so if you point to Hispanic you can find it under Minorities. >> if you want to further define Hispanic, Like Castillian or Mexican they >> can be child of Hispanic >> >> Adrian Crum sent the following on 9/4/2011 11:10 AM: >>> And your point is? That doesn't assign Hispanic to a classification >>> group, it only makes Hispanic a child classification of the Minority >>> Classification. >>> >>> At any rate, I have implemented the pattern I needed locally, and I have >>> given up trying to make the case for an improved Party Classification >>> data model. >>> >>> -Adrian >>> >>> On 9/4/2011 7:04 PM, BJ Freeman wrote: >>>> <PartyClassificationType description="Minority" hasTable="N" >>>> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >>>> <PartyClassificationType description="Hispanic" hasTable="N" >>>> parentTypeId="MINORITY_CLASSIFICA" >>>> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >>>> >>>> >>>> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>>>> 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<[hidden email]> 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<[hidden email]> >>>>>> 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<[hidden email]> >>>>>>> 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<[hidden email]> >>>>>>>>> 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<[hidden email]> >>>>>>>>>>> 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<[hidden email]> >>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |