Re: [Gnumed-devel] Inadvertent deletion of Procedure when Deleting episode

[Karsten Hilbert]

On Thu, Aug 01, 2013 at 06:11:09PM +0000, Jim Busser wrote:

> AND If rows in the clin.clin_root_item table are not supposed to be able to 
> be deleted (except this possibility is hinted at by the missing 1070), why 
> does my table
> 
>       gnumed_v18=> SELECT COUNT(pk_item)
>                                       FROM clin.clin_root_item ;
>        count
>        -------
>        1031
>        (1 row)
> 
> contain only 1031 rows? What happened to the other roughly 40 rows? 

Well, there's two misunderstandings:

1) sequences aren't necessarily gapless

If, say, an exception occurred in an attempt to insert a row
into, say, clin.procedure the insert would be rolled back
but the increment in last-used-sequence-ID would NOT.

2) There aren't really ever any real rows in clin.clin_root_item in GNUmed.

We only ever insert into child tables of clin.clin_root_item
(in fact, INSERTs directly into clin.clin_root_item trigger
an exception). Row data from child tables does not get
*propagated* into parent tables -- it only "shows up"
therein. In other words, clin.clin_root_item is but a
convenient *view* of the common columns each child inherited
from it. So, when deleting a row from a child table the
clin.clin_root_item pseudo row automagically disappears if
everything works as advertised.

So, having a row in clin.procedure but NOT also a pseudo-row
thereof in clin.clin_root_item seems neigh impossible
barring a bug in PostgreSQL AND the insert prevention rule
not having triggered AND a query having been run which does
not even EXIST within GNUmed code.

I will review again what data you have sent so far.

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