I meant data using the criteria you outlined. Regards,
Pieter Bos Op 2 nov. 2017 om 18:25 heeft Pablo Pazos <pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> het volgende geschreven: Hi Pieter, What structure? On Thu, Nov 2, 2017 at 2:21 PM, Pieter Bos <pieter....@nedap.com<mailto:pieter....@nedap.com>> 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 <pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>> 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 <pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>> 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: pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> 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: pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> 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 openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org><mailto:openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org<mailto: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<mailto:pablo.pa...@cabolabs.com> 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 openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
