gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Inadvertent deletion of Procedure when Deleting episode
Date: Fri, 2 Aug 2013 12:10:11 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Aug 02, 2013 at 09:55:15AM +0000, Jim Busser wrote:

> I think that I finally now (better) understand postgres inheritance.
> 
> And so while it can be technically possible to store at least *some* data in 
> the rows of a parent table, as in the example at postgresql.org
> 
>       http://www.postgresql.org/docs/current/interactive/ddl-inherit.html
> 
> it is *not* necessary to do so.
> 
> In fact, in GNUmed, it was decided to prevent do so, and to utilize 
> clin.clin_root_item purely for two other purposes:
> 
> 1. to provide a stable data definition of columns to be inherited by child 
> tables, and
> 
> 2. to make easier, and more efficient, certain queries that involve 
> specifying clin.clin_root_item despite that this table does not, itself 
> directly, contain any rows and therefore accounting for the difference 
> between when I query:
> 
>       SELECT COUNT(*) FROM clin.clin_root_item ;
>       --> 1031 rows
> 
> versus when I query (and here note the 'ONLY'):
> 
>       SELECT COUNT(*) FROM ONLY clin.clin_root_item ;
>       --> 0 rows

Precisely.

> and so any 'loss' of values of pk_item was not because of postgres permitting 
> any deletion of a row in clin.clin_root_item but, rather, that a SELECT 
> performed as
> 
>       SELECT pk_item … FROM clin.clin_root_item
> 
> seemed unable to return a value of 1070 for pk_item despite that I am 
> *pretty* sure (though not 100.00% positive) that this value was still in 
> existence at the time, in a row in the child table clin.procedure as 
> described here:
> 
>       http://lists.gnu.org/archive/html/gnumed-devel/2013-08/msg00002.html

I know, but any chance to further track this down vanished
with your deleting the offending clin.procedure row and your
not being able to reproduce the situation on a second test.

Not a problem, however, I should think.

The bootstrapper now beefs up the schema definition.

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]