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.
