Jacopo,
If we normalize the data and reference PartyRole from
PartyRelationship, and remove the fields:
partyIdFrom
partyIdTo
roleTypeIdFrom
roleTypeIdTo
fromDate
thruDate
And replace them with:
fromRole
toRole
Then we will eliminate this confusion. We would still of course use
PartyRelationship, and not depricate it. In the business login and
security, we will need to check both PartyRole and PartyRelationship
depending on what the service is doing.
For searching, and party lookups, I completely agree with you. We can
still sort them and search role type to obtain a PartyRelationship.
Thank you.
On Sun, Oct 12, 2014 at 1:19 AM, Jacopo Cappellato
<jacopo.cappell...@hotwaxmedia.com> wrote:
> On Oct 12, 2014, at 7:09 AM, Jacopo Cappellato
> <jacopo.cappell...@hotwaxmedia.com> wrote:
>
>> a) deprecating the party role entity
>
> One clarification: I didn't mean to say that we should remove the party role
> entity; in fact it would be still useful because, in order to play different
> party relationship, we will need to store different information for the
> party; the party role entity is useful to tell you what are the roles that
> can be played by a given party; what I meant to say is that in mostly all
> business logics/screens we should replace lookups to party roles with lookups
> to party relationships.
>
> Jacopo
