Re: [Gnumed-devel] Synching

[Karsten Hilbert]

On Mon, Aug 31, 2009 at 03:33:47PM +0200, Thiemo Kellner wrote:

> >The hard problem isn't so much caching of data in
> >disconnected mode but rather resolution of conflicts later on.
> 
> I fully agree that it would be a hard thing to implement a fully
> automatic conflict resolution. I'd even say it is impossible if you
> are to catch all cases. But I also think that it is completely
> unnecessary. The confict can be solved by who ever is trying to
> synch. It just would be handy for the one to have a tool supporting
> this.

I agree. It's still a hard problem. I am all for it to solve
that for GNUmed but it'll bind a lot of resources. Basically
all of them.

> On the other hand, if one took the approach to only add data,

It's not that clear cut. Since a proper practice management
system is more complex than one might think GNUmed does
housekeeping under the hood - such as re-connecting to an
encounter (possibly after asking the user), updating the
status of encounters and episodes, etc.

> would
> it not be possible to have an automatic synch assuming that the
> order of the entries where of no importance. I guess one could even
> get an appropriate time order when the client would save the local
> uncommitted entry with its save timestamp

That is done anyhow as part of auditing.

> and this timestamp would
> get committed to the database as well. Even if we ommitted the
> ordering, conficts would only raise if more than one visit would
> take place in at the "same" time or when the earlier visitor was
> lazy and would not synch as soon as possible. I reckon this is not
> often the case.

What happens is that while the doctor is away on a house
call or nursing home visit the receptionist will scan a
newly arrived referral note or new lab data comes in for
that patient.

> Thinking of all this. Couldn't conficts occur in GnuMed already.

Sure, but those happen within the same database.

> At
> the end it is client server technology and two (or more) clients
> accessing the same data would cache this data and if both of those
> clients changed the data, one would necessarily try to commit with
> outdated base data.

We detect this case by looking at the transaction ID of each
record before commit. We don't, however, do anything
particularly clever about it yet. Our business objects have
got all the necessary bits available: the original data they
initially read from the database, their current locally
modified data, and the data that is in the database now
committed by some other party. However, so far they simply
fail the operation and log all the values.

> Never mind. If master client replication works it will fit my purpose anyway.

It will, but you'll have to be somewhat clever about it:

at the office:

        laptop is slave
        server is master
        laptop syncs from server

going away:

        laptop is promoted to master
        server is demoted to slave and locked

coming back:

        server (now slave) syncs from laptop (now master)
        laptop gets demoted to slave
        server gets re-promoted to master

This doesn't solve what happens when people add data to the
server-as-slave back at the office while the
laptop-as-master is away.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346