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. -David
