[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Idea... cloning patients to facilitate GNUmed demo
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Idea... cloning patients to facilitate GNUmed demo |
Date: |
Sun, 12 Jul 2009 19:46:34 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Fri, Jul 10, 2009 at 08:31:41AM -0700, Jim Busser wrote:
> If and when this would be attempted, would the Person > Merge command
> already identify the tables that need to be touched?
Not all of them by any means but it surely is the best
starting point in the current code.
> It would seem to me
> that the existing "Merge" feature may already be replacing the patient
> identifier in all records related in the merge
That surely is correct but the dump and restore of a single
patient must concern itself will all the dependant tables as
well.
> and presumably causing the
> deprecated versions to move into the audit tables.
That's right.
> In the meantime, I am supposing that what I talked about is best
> achieved either by deleting all patients other than the one I wish to
> create (and export) -- or else starting with a fresh db and
> - creating just the one patient
> - dump the db, save as "One"
> - within GNUmed, modify "one" into "two"
> - dump the db, save as "Two" etc
>
> that way, I can generate 3 versions of the dump, each with the data of a
> single patient.
That would work. However, those three dumps are not
restorable into each other, not even in succession.
> Presumably the dumped data of a single demo patient would also be useful
> to inform mini-projects.
For some projects that could possibly be helpful.
> 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 ?
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346