Jacopo, Thank you a lot. I missed this one. It explains it and removes the confusion.
On Sun, Oct 12, 2014 at 3:10 AM, Jacopo Cappellato <[email protected]> wrote: > Are you sure it is not already implemented like this? > > See the following constraints from the Partyrelationship entity definition: > > <relation type="one" fk-name="PARTY_REL_FPROLE" title="From" > rel-entity-name="PartyRole"> > <key-map field-name="partyIdFrom" rel-field-name="partyId"/> > <key-map field-name="roleTypeIdFrom" rel-field-name="roleTypeId"/> > </relation> > <relation type="one" fk-name="PARTY_REL_TPROLE" title="To" > rel-entity-name="PartyRole"> > <key-map field-name="partyIdTo" rel-field-name="partyId"/> > <key-map field-name="roleTypeIdTo" rel-field-name="roleTypeId"/> > </relation> > > Jacopo > > On Oct 12, 2014, at 9:05 AM, Mansour Al Akeel <[email protected]> > wrote: > >> Jacopo, >> >> The way to enforce the constraints is to define the PartyRelationship >> between pair of PartyRoles, and NOT between partyIds and roleTypes. >> This is what I meant. >> >> >> >> On Sun, Oct 12, 2014 at 2:54 AM, Mansour Al Akeel >> <[email protected]> wrote: >>>>> In this case, we don't need to define the party ids in the >>>>> PartyRelationship, because the PartyRole entity has them. All we do is >>>>> we reference PartyRole(s). >>>> >>>> If I understand, you are suggesting to extend/use PartyRole in place of >>>> PartyRelationship; why not using PartyRelationship instead? >>> >>> Not exactly ! I am suggesting to use BOTH for a PartyRelationship. A >>> party that has a Role of Type MANAGER, can be involved in a MANAGE >>> relationship. >>> In the current setup, any party can get engaged in any relation. So >>> the Party "John Black", does not need to have the PartyRole "Customer" >>> in order to have a relationship with DEF inc. >>> And similarly, ABC inc does not need to have EMPLOYER ROLE in order to >>> have an EMPLOYMENT relationship with other Party. >>> >>> The relationship is defined by two roles. Each role is defined by >>> Party and RoleType. >>> >>> >>>> >>>>> >>>>> >>>>>> Summary: >>>>>> * "party role": the roles that a given party *can* play >>>>>> * "party relationship": the actual roles played by a given party (with >>>>>> respect to other parties). >>>>>> >>>>> >>>>> This clarifies it. But don't we find this confusing ? Why does someone >>>>> get involved into a DEVELOPER relationship if she does not have the >>>>> DEVELOPER PartyRole ? >>>> >>>> It can't. The process should look like: >>>> 1) add developer information to a party and add the DEVELOPER role to it; >>>> this means that now the party can play the role of a developer in some >>>> party relationship >>>> 2) create one or more party relationship where the party is a developer >>>> for some other party >>>> >>> >>> Perfect. So we are on the same page here. This is how I would model >>> it. But the current model doesn't enforce this constraints. It allows >>> the party "Mary" to be involved in a relationship that with >>> "DEVELOPER" RoleType. >>> Please note that she does not have DEVELOPER Role, but the >>> PartyRelationship entity has the fields "roleTypeIdFrom" and >>> "roleTypeIdTo" which allows to break this constraints, and create >>> confusion. >
