On 15/10/2017 12:49, Pablo Pazos wrote:
Hi I'm trying to define a set of rules for a logical delete commit and
have some gray areas that I'm not sure of.
*1. commit after delete flow*
[creation v1] => [modification v2] => [deleted v3] => ?
Can a modification/amendment v4 happen after a delete?
well, a deletion is a deletion, logically. In a non-versioned system,
the data object would literally disappear. In a versioned system, such
as we have, the top version records the fact of deletion, which
logically applies to the whole versioned object.
This is one of those cases that forks in the version tree can happen,
since v2 is deleted by v3, but v1 can be forked and a commit of
modification or amendment can happen on that branch.
it could, if in system A (say in hospital A), the Composition is
logically deleted but in system B (clinic B) a copy of that Composition
(say medications list) is modified with a new version; then if this
modified Versioned object is copied back to system A, system A will see
a branched tree, which communicates the fact that hospital A thinks the
information is no longer there, but clinic B does have a version of this
information.
THis can only be resolved at the organisational level - i.e. by agreeing
what is really going on with the medication list (or whatever the info
object is) between the two HCFs.
But - is there any real scenario where this could actually happen? I
can't imagine System A really wanting to delete the medication list
Composition.
I'm considering the delete only affects a VERSION, not the whole
VERSIONED_OBJECT.
Can a delete logically delete the whole VERSIONED_OBJECT?
that's what it logically means doing.
On a lineal versioning scheme, I'm not sure if an amendment can happen
after the delete. because the semantics of lineal versioning is I'm
versioning v3 not v1 if I do a commit after v3.
I think if a delete happens, that is like killing that branch, so no
new versions can be added.
Is that correct? What do others think?
well as you point out, things might be ambiguous if two systems modify
copies of the same versioned composition, and one of them does a logical
deletion. We probably need to think about this more carefully and update
the documentation. I at least would need to get a better understanding
of the problem first i.e. real use cases.
*2. delete on persistent compos*
Looking at the specs, it is not clear to me how a delete would affect
a persistent composition.
This is an open question.
This is also related with the previous case, since if a version is
deleted on a persistent composition, there will be more commits for it
after the delete, because it is persistent.
Well, deletion should really make the persistent composition act as if
it wasn't there, except for queries in earlier time windows. So I would
say a priori that further commits should be prevented, but - maybe
someone is going to say: what if the deletion was an accident? Maybe
there needs to be a lifecycle operation 'undelete' (or 'undo delete').
*3. delete a non-trunk version*
[creation v1] => [modification v2] => [amendment v3] => ...
Let's say there are many modifications/amendments for a compo, can be
persistent or event.
What happens if a version in the middle of the version tree/line is
deleted?
that can't happen - a deletion can only happen as the top version.
If we were talking about Git or some other typical system, deletion
makes it look like a file is actually gone, and subsequent commits will
create a new file of the same name, but whose version lineage is
disconnected from the previous one. We could add something to the spec
to force something like that behaviour.
- thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
