Hi Bert, On 19/04/2011 11:54, Bert Verhees wrote: > Hi, > > Excuse for the bit complex text below, I don't know how to say it more > simple > > > I have a small problem with the way ReverseRelationships are connected > to Party in the Demographic RM. > Maybe my problem is because of my misunderstanding. > > The problem is not only conceptual, but it also causes problems in > coding (programming) the kernel. > > The problem is that ReverseRelationships are a Set of LocatableRef. > This means that the PartyRelationship has to be stored before it can > be added to a party ReverseRelationship list. > The PartyRelationship has to be stored because LocatableRef takes a > ObjectVersionID as constructor-argument.
I presume this is in the Java implementation, since constructors are not defined in the openEHR specifications? Obviously using constructors is not the only possibility, setter routines could also be used. IN any case, creation of identifiers does not rely on persistence; it should be knowable beforehand, so I would expect the use of a constructor to be fine. > > The conceptual problem is that the ReverseRelationship in this way is > defined as a version of a specific PartyRelationship. If the > PartyRelationship changes, for example in its details, than the new > version is not anymore connected to the target-Party, or this > connection needs extra code to restore > > /(replace the ObjectVersionID in the target-Party > ReverseRelationship-set, maybe even create a new version of the PArty, > because of a new version in another object, namely the > PartyRelationship-object) > / the reverse_relationships attribute of PARTY is intended to contain a set of reverse pointers to PARTY_RELATIONSHIPs for which the PARTY is a 'target'. The first thing to note is that the attribute is optional, and you can ignore it if you want. If you use it, it should always contain the current list of PARTY_RELATIONSHIPs for which the PARTY is a 'target'. If any such relationship is changed, then the relevant PARTYs would have to be updated. The problem you point out is that if the change in the PARTY_RELATIONSHIP (taking it from version 3 to 4, let's say) doesn't affect a given PARTY, which is a target of version 3 of the PARTY_RELATIONSHIP, then you are still forced to update the PARTY so that it its reverse_relationships now has the v4 id for the updated PARTY_RELATIONSHIP rather than the v3 id. One way to fix this would be if we were to enable a 'latest' version id that always automatically pointed to the latest version of something. This is defined for openEHR EHR URIs, but not for the type OBJECT_VERSION_ID, used in LOCATABLE_REF. I think a better solution is that PARTY simply does not contain reverse relationships, because it is essentially solving a database indexing problem, which could be better solved by maintaining index objects and/or native indexes, depending on how the demographic model persistence is implemented. > // > I don't understand why that is, it seems a bad thing which causes > extra complexity. > More logically would seem to me to connect the UID of to the list > ReverseRelationships in the target Party, instead of the ObjectVersionID. that would probably risk the reverse_relationships attribute getting out of data quickly and containing wrong information, unless the implementation meticulously checked whether the validity was always maintained or not. I would be interested to know what other experience there is with this attribute; my suspicion is that it should be deprecated. - thomas* * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110428/433f3de8/attachment.html>
