On 5/13/2011 1:53 PM, David E Jones wrote:
On May 13, 2011, at 1:47 PM, Adrian Crum wrote:
On 5/13/2011 1:36 PM, David E Jones wrote:
On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
The CustRequestParty entity seems to be an implementation of the Request Role
Type entity in The Data Model Resource Book. Besides the name difference, the
only other difference is using Role Type instead of Request Role Type. Reusing
Role Type in this way is okay from my perspective. The problem is, the
CustRequestParty entity isn't related to Role Type, instead it is related to
PartyRole - which requires a PartyRole entry.
That is an extremely limiting relationship - a party can't be related to a
Request in a particular role unless they are already a member of that role.
Pretty much all *Role and *Party entities are setup this way, and in fact
nearly all entities that have pairs of partyId and roleTypeId have a type one
relationship to PartyRole. This is a pattern that goes back to the beginning of
OFBiz and is used throughout the project.
I agree with making the change so that all of these have fks to Party and
RoleType separately, so not requiring an entry in PartyRole, but keep in mind
that's a big change. I've actually done this in the Mantle UDM, but that was
easy because there aren't any dependencies on that data model yet... for OFBiz
it's a bit more work.
BTW, this goes back to the original pattern for party roles where the concept was that a
party being in a role (ie with a PartyRole record) means nothing, and roles should just
be used to define how parties are related to other records in the system. However, no one
seems to want to follow that pattern so by de facto practice it's a moot point, and IMO
ideally we would get rid of PartyRole altogether, or use it for specific and limited
circumstances. The reason is that 99% of the time someone comes up with a constraint like
"Party X is in Role Y" they are forgetting other important details, like in
Role Y for Record Z.
Thanks for the reply!
I don't think this particular change is a big one. I suspect the relationship
can be changed without much fuss, but I will check into it further.
There shouldn't be any confusion about Party Role if we follow the author's
reasoning for it: It is intended to describe the party's role in the enterprise
or organization. In Request Role, the relationship being described is a party's
role in the request, not the party's role in the enterprise. That's why Request
Role is related directly to a Role Type and not a Party Role.
Yeah, this is exactly the sort of misunderstanding I'm referring to. You wrote "It is intended
to describe the party's role in the enterprise or organization" and "not the party's role
in the enterprise. That's why Request Role is related directly to a Role Type and not a Party
Role."
However, a record in PartyRole is NOT meant to represent a Party's role within
the enterprise or organization, if you want to model that you should have a
PartyRelationship record going between the Party record for the enterprise or
organization... not a PartyRole that just ties a partyId to a roleTypeId
without any consideration of the enterprise or organization. It's inflexible
and generally bad modeling, and if something in The Data Model Resource Book
seems to describe it this way I'd be surprised, chances are whatever you think
means this really means something else.
Right. I over-simplified the meaning of Party Role to demonstrate the
differences in this case. Thank you for the clarification.
Semantics aside, we agree that the existing entity relationship I
described is incorrect, right?
-Adrian
