[Top][All Lists]

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

Re: [Gnumed-devel] gui elements

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] gui elements
Date: Thu, 11 Nov 2004 17:38:23 +0100
User-agent: Mutt/

> - createlang didn't work with a configured gnumed super-user, but
it needs to be run by the PostgreSQL superuser

> - there is no merge /export mechanism for logical record groupings such
> as per identity. The use case was I had entered the details of several of
> nursing home patients as a trial , and was able to generate html summary
> pages . These are not importable.
Sure they are. Save and import them as documents ;-)

> When I did a reload of the schema, the
> sequence start values were restarted, and I had already entered another
> patient on the reloaded schema.

> - I think Carlos was on the way to doing a file export in the python client;
Yes, done-for-now.

> can it re-import , even on restarted schemas ?
No, except as a "binary" document. However, import/export
doesn't relate to "original" vs. restarted schema. Any semantic
im-/exporter (eg at the business logic level such as "a
patient" or "an EMR" vs. database dumpers) that relies on
primary keys not changing across an import/export cycle is
broken in the first place. Even in the test data SQL files we
use for bootstrapping we don't rely on previous primary keys.
We rather retrieve them at runtime, either via currval() or
even a subselect.

> - another solution, which would be just as pervasive a problem to weave in
> , is to use unique time-place-machine/identity  id values ( like a global
To solve which problem ? In-database metadata such as primary
keys should never ever be of used outside the database in fear
of them acquiring business meaning. In light of this it is
probably good that PostgreSQL makes re-using sequence
values rather painful.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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