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. 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) / 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. Maybe it is a matter of redefining the LocatableRef-definition to a kind of ObjectRef-class, and add a VersionedLocatableRef for versioning-purposes. -- The programming problems are also difficult, and the most important reason for that is that in this way PartyRelationship (/and possible also Party/) needs another treatment than other Locatables, although, in my kernel. I hate these situations which make code complex, disturb coding/pattern concepts --------------- But maybe it is all a stupid mistake which causes a blind spot in my thinking. I appreciate any advise very much Thanks Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110419/a9638078/attachment.html>
