On Thu, Nov 2, 2017 at 3:01 PM, Thomas Beale <thomas.be...@openehr.org> wrote:
> > 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. > Logical deletions don't make data disappear, even if it's not under a versioned system. > In a versioned system, such as we have, the top version records the fact > of deletion, which logically applies to the whole versioned object. > That sort of works on a lineal versioned system, the specs are not clear in terms of how to handle a deletion in a distributed versioned system. I agree delete should be considered to affect the status of the whole versioned object, but on a branching scenario this is not so well defined or maybe can't be implemented at all (see below ***). The issue I see with versioning for deletion is that amendments, modifications, etc. are defined at the same level of the deletions, and the other modification types apply to the latest version, not to the whole composition. Considering this: shouldn't delete be specified on it's own, separated from other change types? I always had doubts about using a commit to delete something, and now I'm starting to understand why :) > > > 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. > *** That kind of contradicts the "deletion logically applies to the whole versioned object", since the versioned object is unique, independently of which system has a copy of a version from that versioned object. On a branching case, the delete seems to only affect a branch. > > 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. > > Besides the delete case, that is the issue of merging branches, IMO is always an organizational issue. We had another thread were we talked about lineal vs. distributed/branching versioning. > 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. > > Change medication list for X and I think we will have cases. If we don't have cases, why do we included this on the specs? A related issue, is if a delete happens by mistake, how can someone "undelete" if no more commits are accepted on that branch after the delete? I think it would be useful to accept commits, like amendment, because maybe the data is not incorrect, but the previous delete commit was incorrect. In that sense, when a logical delete happens on a system, a good feature is to have a view of the deleted elements and allow users to undelete them, like a trash bin. IMO if delete can be executed by a user, undelete should also be executed by a user, not by the organization. > > 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. > > Rethinking that, I'm not sure if killing a branch is correct, since I see the undelete case (mentioned above) happen if delete is allowed. In terms of the spec, I'm worried about what the spec allows and try to fill the blanks the spec doesn't provide. I'm not sure why allowing something in the spec if we don't have use cases to support that. Maybe the easiest would be to remove the delete cases from the spec and delegate that to each implementation. Some may support it, some may support undelete, some may apply the delete to the latest version, some may apply it to the whole versioned object, others will support logical and physical deletes, etc. There are too many cases to define all of them in an unambiguous way. > > > > *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'). > > That is exactly what I was thinking of while writing :) But! as I said, I'm not sure if delete/undelete should be handled at the change type level, it seems to be a concept on a different level than create/modification/amendment. > > > > *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. > is that specified? > > 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. > In Git, If I checkout v2 on a new branch, and there are v3, v4, ..., in the master branch. If a file is deleted on the new branch, and I commit the branch, the file won't be there for that branch, and master (v3, v4, ...) won't notice about that. All issues will happen when I try to merge my branch with master, there I need to decide if I keep or not the file that is a difference between the two branches. The real issue here is now to merge, not the delete itself. But, the semantics of a delete happening on a branch should be specified. I think most implementation won't implement merging, so this case might not happen. But if the specs support branching, the merging process and handling deletions on branches while merging should be specified. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez e: pablo.pa...@cabolabs.com p: +598 99 043 145 skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
