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
<mailto: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
