Re: [Gnumed-devel] bootstrapping database problem

[Karsten Hilbert]

On Tue, Jul 22, 2008 at 06:42:26PM +0200, Florian Hubold wrote:

>>> That would be my last question:
>>> There is a patch in the gnumed-server package which disables interactively
>>> runnning the bootstrapping script.
>>>     
>> That patch is strange (but who am I to discuss with a
>> volunteer packager).
> I don't know if that patch is strange
Well, it works, so it's obviously getting the job done. But
the proper way would've been to set the option in the conf
file. Paul just didn't know that, I suppose.


>, it was not written by me,
I know.

> so i only questioned whether this is yet the right way to do this.
> I'll drop the old one and patch the config file instead as you suggested.
Sounds a lot saner to me.

>> I have improved this behaviour for the next release (0.3).
>> It now only asks whether or not bootstrapping is really
>> wanted when the (latest - 1) database appears to exist.
>> Usually one would want to run the upgrade script in that
>> case.

Oh, and it drops the database from inside the bootstrapper
itself now which is controlled by another option in the conf
file ...

> Sounds really good. I'll look for a clean way to integrate the upgrade
> script during rpm package installation, but this has to be foolproof.
I have experienced the fear when upgrading the
Praxisprogramm of a practice here in Germany often enough
:-)

GNUmed is nearly foolproof in the upgrade process:

1) it takes a backup of the existing database
2) it clones the existing database into a database with the new name
3) it then performs transformations on the new database only, the old
   one isn't touched at all, in fact, it isn't connected to anymore
4) calculates a hash value of the table *structure* of the new
   database and checks that against a known expected hash
5) performs developer defined sanity checks on the *data* in
   both databases (eg compares the number of patients, documents,
   etc)

Only if all that works out the database is declared to be
converted successfully.

So, whenever something goes wrong people can

a) go back and just continue using the old database and client
b) safely retry upgrading any number of times

To safeguard connecting to the new, faulty database with the
old client (or vice versa) the client re-checks the database
hash against an expected value at startup. It then refuses
to connect to that database.

I would never do without all that :-)

> Will investigate and report back.
Yes please.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346