Hi Bert the case you mention is not versioning control, is concurrence control. Not sure which system will allow two users to insert invalid data on an item when the archetype constraint says it is not valid. If that is an implementation, I don't think it is secure in terms of concurrence.
Versioning would be when a uses commits a document that is "complete". IMO incomplete compos should not be final versions, and if one user is working on an incomplete version, no other user can work on that (read-write work). If two users need to read-write incomplete compos, then 2 separate versions are needed and there you have branches. Linear versioning would not allow to create branches, and new versions would not be created until the user that has the current version in read-write mode finishes and commits the completed version. That is the only way to keep it linear, with locks. Not sure about removing the current approach from the specs, but creating a simpler alternative might be of use to enable more and quicker implementations. On Wed, Jun 21, 2017 at 5:42 AM, Bert Verhees <bert.verh...@rosa.nl> wrote: > On 21-06-17 10:19, Pablo Pazos wrote: > > Hi Bert, see below > > On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees <bert.verh...@rosa.nl> > wrote: > >> Hi Pablo, I did it a few years ago, just dumped not-current versions in a >> slow XML database, because, in normal cases they are never queried, and >> when they need to be queried, there can always be found a faster solution. >> >> But of course, this was a linear version system. ExistDB supports >> distributed versioning on XML out of the box. And you can also use a >> normal, not OpenEHR, version system like Git or VCL. >> >> But when looking at how OpenEHR works, is there ever need of merging? Do >> people edit concurrently same datasets? I think they are they always >> working on new versions of datasets, there is only one exception, that is >> the persistent Composition, there could occur merging problems. >> >> The openEHR versioning mechanism is like Git. The problem I see with this > approach is that real users don't want to deal with that level of > complexity just to track changes in a distributed way. openEHR allows > branching, so if there is no merging, each user can be working on a > different branch, seeing just part of the data. Merging is complex, but > that is needed only if branching is allowed, so the problem is really > branching. > > > Merging and keeping the data within the constraints of the archetypes is > nearly impossible to do automated. > Because, what do you do when person A adds an item to a structure and at > the same moment person B adds an item to the same structure, but in the > archetype is defined that in that specific structure only one item is > allowed. > > There you have the problem, inconsistent data because of merging. > > I agree with you that distributed versioning is not feasible, even, > sometimes, dangerous. It would be good to remove it from the specs. > > Bert > > _______________________________________________ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > implementers_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 Skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com pablo.pa...@cabolabs.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
