[Top][All Lists]

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

Re: [Gnumed-devel] limbo table entries

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] limbo table entries
Date: Wed, 22 Jan 2003 23:36:10 +0100
User-agent: Mutt/

> Maybe I'm wrong, but I could see some use for a limbo state on
> updates, too. Imagine a user starting to enter a new form (prescription
> etc.). The client might want to prefill all fields with a default value.
> A subsequent update of this prefilled fields could be securely limboed
> until the action of filling the form will be finished. A signal
> "update_finished" could be sent by the client clearing the limbo flag
> thereby enabling auditing this version.
This particular case - which is a very valid use-case, I
encounter it several times daily - can easily be dealt with by
a dedicated table called "nascent_form_instances".

> IMHO the semantics of INSERT and UPDATE are a little bit confusing here.
> At database level it means the creation or change of a single row in a
> table or view. At user level it means the creation or change of complex
> objects. That's why we might need a little bit more communication between
> client and backend to confirm that the client object (whatever that be)
> has been finished and should be inserted as a whole.
True enough. See Horst's separation of database objects vs.
business objects in that other post.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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