Re: [Gnumed-devel] limbo table entries

[Karsten Hilbert]

> 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.

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