[Top][All Lists]

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

Re: [Gnumed-devel] forms handling / NetEpi

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] forms handling / NetEpi
Date: Wed, 27 Jun 2007 14:42:12 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Jun 27, 2007 at 02:12:03PM +0200, Karsten Hilbert wrote:
> Subject: Re: [Gnumed-devel] forms handling / NetEpi
> User-Agent: Mutt/1.5.13 (2006-08-11)
> On Wed, Jun 27, 2007 at 07:02:27AM +1000, Tim Churches wrote:
> > >> Easier extensibility of the form definitions/metadata,
> > > I can see that. Put IOW: it seems safer to update data in
> > > deployed databases rather than requiring the databases
> > > themselves to be modified, eg. when one needs a new "field"
> > > in the form metadata definition.
> > > 
> > > It *can* be done via ALTER TABLE but I agree it sounds safer
> > > to rather do UPDATE ... WHERE ... ;
> > 
> > What if the update to a form which has already been used to collect data
> > involves the removal of a column? If you use ALTER TABLE, all the data
> > collected in that form field/column is now gone... where's the undo button?
Oh, I just noticed a misconception here:

An ALTER TABLE on the form definition table wouldn't even
affect any data column in any way. It would affect
*attributes* on a field definition to exist/not exist. The
actual field defs themselves would be rows in that table.

Actual *data* for said fields would be foreign keyed to the
field def so as long as there's corresponding data deletion
of a field def could be "guarantueed" to not occur.

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]