gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] patient object - backend listener


From: Karsten Hilbert
Subject: [Gnumed-devel] patient object - backend listener
Date: Wed, 5 Feb 2003 18:11:19 +0100
User-agent: Mutt/1.3.22.1i

While working on a patient object I finally encountered the
problems others have probably seen before:

I register interest in the backend notification
"patient_modified.$ID".

Now, imagine the following situation:

A retrieves patient X
B retrieves patient X, too
A modifies patient X locally
B modifies patient X locally, too
A commits patient X to backend
B now receives notification of update by A

1) what is B to do ?
2) how does B know whether or not the updates conflict ?

AFAIK, usually one would associate a timestamp with a row that
gets updated when the row is updated (audited, that is).

If we retrieve the timestamp upon data retrieval, later change
the data but not the timestamp in the local cache we can
detect the data that changed by checking the cached timestamp
against the current db timestamp (if nothing had changed locally
we would just refresh the cache).

Do we need to add timestamps or are there better ways to do
this ?

"Select for update"/standard locking doesn't do as we want
several clients to be able to change data simultaneously and
we don't have control over local changes anyways. The problem
only appears upon trying to merge multiple local
modifications.

Or will we display a three line salute and let the user make
up her mind ?

1) _original_content_of_item____
2) _current_content_in_database_
3) _our_changes_to_content______

"Please select the version you want to keep !"

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]