[Top][All Lists]

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

[Gnumed-devel] limbo table entries

From: Horst Herb
Subject: [Gnumed-devel] limbo table entries
Date: Sun, 19 Jan 2003 20:52:11 +1100
User-agent: KMail/1.4.3

I have spent much of this weekend working on the Gnumed client database API. I 
ran across a few conceptual problems. To solve one of tjhem, I would propose 
the concept of "limbo records" in gnumed.

A limbo record is a temporarily non-audited record, allowing any number of 
changes while in limbo state.
Reason: with complex widgets and complex tables in the setting of alpha or 
beta quality software (or on unstable platforms like Windows) a system crash 
could lead to significant data loss unless the data is not saved in regular 
Furthermore, the work flow of some doctors includes postponing writing the 
records until the evening.
All this would create a monstruous blow-up of our audit trail, since it would 
rquire several updates to records.

If audited tables would carry a "limbo flag", the folowing would happen:
1.) the record is created, the limbo flag of the record is set. Table and OID 
are recorded in a "limbo table".
2.) any number of changes can be made to the record as long as the limbo flag 
is not unset: the "ON UPDATE" trigger function that writes to the audit trail 
checks the limbo flag, and if set, it exits
3.) Either programmatically or via a "limbo daemon" (or both) the limbo flag 
is unset (at the end of the day, at midnight, after a week, when a new 
patient is selected).

Reasonably secure approach, since once the limbo flag has been unset, the "ON 
UPDATE" trigger would disallow setting it again. Would reduce backend traffic 
and audit log size considerably, and make clients more fault resistant 
through frequent saving of user entries.

Doesn't require much work either: all I have to do is modify the "audit trail" 
trigger generator script a little, and have the limbo table created. Since 
the limbo flag would be inherited via the "audit" parent, no changes need to 
be made to existing table design either (unless the tables already contain 


reply via email to

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