I don't think I'm generalizing anything. The book is pretty specific and clear: 
Party Classification is an intersection entity that sets up a many-to-many 
relationship between the Party entity and the Party Type entity.

I understand OFBiz deviates from the book here and there, and if this is one of 
those cases, then I'll ask again: Why was it done that way?

I'm trying to make sense of the OFBiz Party Classification model, and so far it 
doesn't make sense. The way it is set up, I can't give a party a classification 
without first creating a classification group, assign a classification type to 
it, and then assign the party to the classification group using party 
classification.

In the book it's much simpler - I just assign a party type to a party using a 
party classification. Classification groups are Party Classification sub-types 
and they aren't necessary unless I want to group things a certain way.

-Adrian

--- On Mon, 1/3/11, David E Jones <d...@me.com> wrote:
> I think you may be taking the specific term "type" and
> generalizing it. Consider that *Type entities in OFBiz mean
> something very specific, and it is different from the more
> general use of the term in the book.
> 
> -David
> 
> 
> On Jan 3, 2011, at 3:24 PM, Adrian Crum wrote:
> 
> > That's not what the book shows. There is a simple
> relationship:
> > 
> > Party -> PartyClassification -> PartyType
> > 
> > If you want to group classifications, give them
> parent/child relationships, etc then you do it with
> PartyType, not PartyClassification. Look at table 2.3 on
> page 32.
> > 
> > -Adrian
> > 
> > --- On Mon, 1/3/11, BJ Freeman <bjf...@free-man.net>
> wrote:
> >> how about a pattern of parent child
> >> for PartyClassification of supertype 
> >>   and the sub types then use a
> table for the
> >> attributess of the subtype.
> >> this would allow walking the parnent child
> relationships.
> >> PartyClassification 
> >>
> --->organizationClassification---->minorityClassification
> >>             
>   
> >>            
> >>    ---->industryclassification
> >> 
> >> =========================
> >> BJ Freeman
> >> Strategic Power Office with Supplier Automation 
> >> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> >> Specialtymarket.com  <http://www.specialtymarket.com/>
> >> Systems Integrator-- Glad to Assist
> >> 
> >> Chat  Y! messenger: bjfr33man
> >> 
> >> 
> >> Adrian Crum sent the following on 1/3/2011 2:46
> PM:
> >>> PartyClassificationGroup should have a
> one-to-one
> >> relationship with an entity called
> >> PartyClassificationGroupType.
> >>> 
> >>> -Adrian
> >>> 
> >>> --- On Mon, 1/3/11, BJ Freeman<bjf...@free-man.net>
> 
> >> wrote:
> >>>> so the Party Classification Group
> >>>> table would have a one to one with
> >>>> Classification Types
> >>>> or vica versa.
> >>>> 
> >>>> 
> >>>> =========================
> >>>> BJ Freeman
> >>>> Strategic Power Office with Supplier
> Automation
> >>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> >>>> Specialtymarket.com<http://www.specialtymarket.com/>
> >>>> Systems Integrator-- Glad to Assist
> >>>> 
> >>>> Chat  Y! messenger: bjfr33man
> >>>> 
> >>>> 
> >>>> Adrian Crum sent the following on 1/3/2011
> 1:41
> >> PM:
> >>>>> Looking into this more, The Data
> Model
> >> Resource Book
> >>>> mentions classification groups - but I
> believe the
> >> author
> >>>> meant that Party Types could be grouped
> together
> >> in
> >>>> classification groups. In other words,
> the
> >> classification
> >>>> groups are defined by the data contained
> in the
> >> Party Type
> >>>> table - not in a separate "Party
> Classification
> >> Group"
> >>>> table. There is nothing stopping us from
> having a
> >> Party
> >>>> Classification Group table, but it should
> group
> >> Party Types,
> >>>> not "Classification Types."
> >>>>> 
> >>>>> -Adrian
> >>>>> 
> >>>>> --- On Mon, 1/3/11, Adrian Crum<adrian.c...@yahoo.com>
> >>>> wrote:
> >>>>>> Looking at The Data Model
> Resource
> >>>>>> Book and the way OFBiz models
> Party
> >>>> Classification, it
> >>>>>> appears to me OFBiz models it
> wrong.
> >>>>>> 
> >>>>>> According to the book, the Party
> >> Classification
> >>>> entity ties
> >>>>>> a Party to a Party Type with a
> from and
> >> thru
> >>>> date.
> >>>>>> 
> >>>>>> In OFBiz, the Party Classification
> entity
> >> ties a
> >>>> Party to a
> >>>>>> Party Classification Group with a
> from and
> >> thru
> >>>> date. The
> >>>>>> Party Type is tied directly to
> Party with
> >> no from
> >>>> and thru
> >>>>>> date.
> >>>>>> 
> >>>>>> Was that intentional? Why was it
> done that
> >> way?
> >>>>>> 
> >>>>>> -Adrian
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> > 
> > 
> > 
> 
> 



Reply via email to