gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Idea... cloning patients to facilitate GNUmed demo


From: Jim Busser
Subject: Re: [Gnumed-devel] Idea... cloning patients to facilitate GNUmed demo
Date: Sun, 12 Jul 2009 22:03:03 -0700

On 12-Jul-09, at 10:46 AM, Karsten Hilbert wrote:

Should such a demo patient better first have 

data entered in all tables, without which untouched (empty) tables may be 

omitted from the data dump?


I am not sure I understand what you are asking here ?


I was assuming (maybe incorrectly, but to be on the safe side) that -- for example -- if a patient had allergy information entered, then that allergy information (and the table structure on which it depends) would be included in the dump, whereas if no such information was entered, the dump might omit the allergy table since it did not contain anything related to the patient of interest.

In other words, I was assuming that the dump procedure somehow knows how to maintain referential integrity, so that an attempt to "do-like-dump" a record, on whose key other tables depended, would cause these other tables' related data to be included automatically.

But maybe a dump of data is either all-or-none, and what is required instead to "fully export a patient in SQL" would be to specify, explicitly, every table from which every record of interest would have to be "equivalent to dumped".

I was also thinking that an attempt to delete a (test) patient will also cause postgres to complain and inform the user, via a helpful error log, of the basis for refusal when it would be referential integrity. I was assuming that all tables that contained data related to a person would be required to have a non-NULL value for the person but maybe not every such table requires the original person record to still exist?

reply via email to

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