Re: [Gnumed-devel] Observations & questions about GNUmed

[Karsten Hilbert]

On Tue, Oct 09, 2007 at 08:25:59AM -0400, Dave Cramer wrote:

> So where this all came from is: I'd possibly like to use the gnumed schema 
> as the basis of an EMR.
> There are a number of tools which facilitate database access : hibernate 
> for java, nhibernate for .NET
> SQLObject for python ( there may be others but I'm not familiar with python 
> ), etc. The two variants of hibernate allow the use of optimistic locking. 
> As far as I could tell xmin was the only thing that blocked my use of 
> hibernate.
Oh, as far as that goes you are by no means *forced* to use
XMIN. We just do in the Python middleware to obtain
optimistic locking ...

If one were to write a hibernate based Java client one would
be free to ignore XMIN handling at the cost of not being
able to detect cross-tx concurrency problems with
concurrently running clients of ours.

Are you saying to you *want* to use optimistic locking but
hibernate *inhibits* you from using XMIN as the change
indicator ?

One solution to that would be to, indeed, switch to a user
level change indicator as you suggested. However, to get the
best value from that approach we would then want the
database to automatically set the change indicator upon
COMMIT of an UPDATE (by means of a trigger, say). The reason
being that I would want the lowest possible level to make
sure higher levels can detect concurrency problems. IOW it's
not the job of the middleware to *enable* detection
(detection, yes, just not *enabling* detection).

But then, I wonder, what's the semantic difference to XMIN
(apart from conceptual fragility which we discussed) ?

>> As I said: I am open to patches.

> But being involved in other projects I empathize with your response.
:-)

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