gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Upgrade psql


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Upgrade psql
Date: Sun, 24 Nov 2013 23:47:04 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Nov 24, 2013 at 05:31:18PM +0530, Vaibhav Banait wrote:

And, indeed:

Your ...

> gnumed_v18=# \d clin.substance_intake

...

> Foreign-key constraints:
>  "substance_intake_fk_drug_component_fkey" FOREIGN KEY (fk_drug_component) 
> REFERENCES ref.lnk_substance2brand(pk) ON UPDATE RESTRICT ON DELETE RESTRICT
>  "substance_intake_fk_substance_fkey" FOREIGN KEY (fk_substance) REFERENCES 
> ref.consumable_substance(pk) ON UPDATE CASCADE ON DELETE CASCADE
> Referenced by:
>  TABLE "clin.lnk_substance2episode" CONSTRAINT 
> "lnk_substance2episode_fk_substance_fkey" FOREIGN KEY (fk_substance) 
> REFERENCES clin.substance_intake(pk) ON UPDATE CASCADE ON DELETE RESTRICT

... lacks the appropriate foreign keys into
clin.episode and clin.encounter.

Now, this doesn't necessarily mean your data IS broken,
only that it CAN get/have gotten broken.

Since we've discovered that vulnerability a while ago
the bootstrapper contains code to check for - and
add if needed - those foreign keys. So if you run
the 18 -> 19 upgrade, and provided your data is
consistent even without the FKs, you will end up
with a database fully equipped with the necessary
foreign keys.

Also, the schema hash now takes into account such
foreign keys and will not let clients collect if
those keys don't exist in order to prevent such
mishaps in the future. Maybe that's the explanation
for the various reported hash mismatches ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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