Thanks, Thomas, for your reply.
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.
It is true this is in a java-implementation.
But the way to assign a ObjectVersionID to a version-able object in my code is to persist it, after which my code does some checks, also on versions, and then returns the ObjectVersionID.
This can be re-coded, I could predict the ObjectVersionID, reserve it (protect it against other threads trying to do the same simultaneously), and first create the LocatableRef, then set it in the target-Party which needs the ReverseRelation and if no exceptions occur then persist the PartyRelationship.
As you can see, this will be very complex code.
The way I solved the problem now does also not deserve a prize in a beauty contest (dutch saying).
I describe it to illustrate which problems this situation causes to me.
I, first, persist the PartyRelationship, then try to assign it to the source and target, and if that fails, for example because the archetype of the source-Party does not allow that (or any) PartyRelationship to be assigned, than I need to remove the persisted PartyRelationship. Because my persistence-code does not have any removal (from persistence)-code, I have to assign the orphaned and persisted PartyRelationship as “deleted”, which is not a nice solution, but does not put a (relatively) heavy load on my kernel-functionality.
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.
This is a good idea, there shouldn’t be any optimization attributes in the RM-specifications. It is always possible to retrieve ReverseRelationships at the moment of getting a Party from the persistence-layer.
Thanks, this is the best solution, it really helps me further.
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 don’t understand, my code always retrieves the latest version of a persisted object, when queried by UID. The version-functionality is not yet used in an API. But the storage is already prepared to use it in the future, so, there is code, and are tables and indexes already in use (data are stored), for when that API will come, (which will be within a year or so)