I shouldn't write in the middle of the night, while travelling. Of course the deleted status is in the version, not in the composition. Sorry for confusing reply.
Have a nice day Bert Op vr 3 nov. 2017 05:36 schreef Bert Verhees <[email protected]>: > In a versioned system there is no status for "deleted" necessary *inside* > a composition. The system itself marks the composition deleted. With this > in mind it seems to me the semantical meaning of the inside "deleted" > status is meant for something else. > > Bert > > Op do 2 nov. 2017 20:01 schreef Pieter Bos <[email protected]>: > >> I meant data using the criteria you outlined. >> >> Regards, >> >> Pieter Bos >> >> Op 2 nov. 2017 om 18:25 heeft Pablo Pazos <[email protected] >> <mailto:[email protected]>> het volgende geschreven: >> >> Hi Pieter, >> >> What structure? >> >> On Thu, Nov 2, 2017 at 2:21 PM, Pieter Bos <[email protected]<mailto: >> [email protected]>> wrote: >> You would be able to import this structure into our implementation and it >> would work the same way. >> >> Pieter >> >> Op 2 nov. 2017 om 17:24 heeft Pablo Pazos <[email protected] >> <mailto:[email protected]><mailto:[email protected]<mailto: >> [email protected]>>> het volgende geschreven: >> >> Until we have a clear criteria for commits after delete, I'll use this: >> >> 1. lineal versioning (no branching) >> 2. "deleted" compositions can be "undeleted" using "modification" change >> type, since we don't have an "undelete" change type >> 3. if current latest version is "deleted" the composition won't appear on >> query results >> >> >> >> On Sun, Oct 15, 2017 at 11:49 AM, Pablo Pazos <[email protected] >> <mailto:[email protected]><mailto:[email protected]<mailto: >> [email protected]>>> 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? >> >> 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. >> >> I'm considering the delete only affects a VERSION, not the whole >> VERSIONED_OBJECT. >> >> Can a delete logically delete the whole VERSIONED_OBJECT? >> >> 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? >> >> >> >> 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. >> >> >> >> 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? >> >> Can that even happen? >> >> What happens with the created versions after that? >> >> In my head those versions created on the branch of a deleted version >> should also be deleted if deletes are accepted in the middle of the tree. >> The other rule can be only accept deletes on the latest versions. >> >> >> What do you think? >> >> >> -- >> Ing. Pablo Pazos Guti?rrez >> e: [email protected]<mailto:[email protected]><mailto: >> [email protected]<mailto:[email protected]>> >> p: +598 99 043 145<tel:%2B598%2099%20043%20145><tel:099%20043%20145> >> skype: cabolabs >> [ >> https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ] >> <http://cabolabs.com/> >> http://www.cabolabs.com<http://www.cabolabs.com/> >> https://cloudehrserver.com<https://cloudehrserver.com/> >> Subscribe to our newsletter<http://eepurl.com/b_w_tj> >> >> >> >> >> -- >> Ing. Pablo Pazos Guti?rrez >> e: [email protected]<mailto:[email protected]><mailto: >> [email protected]<mailto:[email protected]>> >> p: +598 99 043 145<tel:%2B598%2099%20043%20145> >> skype: cabolabs >> [ >> https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ] >> <http://cabolabs.com/> >> http://www.cabolabs.com<http://www.cabolabs.com/> >> https://cloudehrserver.com<https://cloudehrserver.com/> >> Subscribe to our newsletter<http://eepurl.com/b_w_tj> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected]<mailto: >> [email protected]><mailto: >> [email protected]<mailto: >> [email protected]>> >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected]<mailto: >> [email protected]> >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> -- >> Ing. Pablo Pazos Guti?rrez >> e: [email protected]<mailto:[email protected]> >> p: +598 99 043 145 >> skype: cabolabs >> [ >> https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ] >> <http://cabolabs.com/> >> http://www.cabolabs.com<http://www.cabolabs.com/> >> https://cloudehrserver.com<https://cloudehrserver.com/> >> Subscribe to our newsletter<http://eepurl.com/b_w_tj> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected]<mailto: >> [email protected]> >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
