[Top][All Lists]

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

Re: [Gnumed-devel] Re: Development testing on Production (?) servers --

From: James Busser
Subject: Re: [Gnumed-devel] Re: Development testing on Production (?) servers -- was 0.3-rc4 released
Date: Thu, 04 Sep 2008 08:40:07 -0700

On 19-Aug-08, at 6:48 AM, Karsten Hilbert wrote:

On Mon, Aug 18, 2008 at 09:02:52PM -0700, James Busser wrote:
It just occurs to me that at the point of upgrading to version (current
+1) of the database, there is a danger in all of the old clients
remaining pointed to the (now deprecated) database
It is not just a danger but rather it will be so unless
explicit action is taken.

However, the bootstrapper runs a locally definable script
before and after bootstrapping which can do pretty much
anything. That script is run if it exists and will not ever
be changed by the GNUmed team.

It would also be fairly easily doable to reconfigure the
source database to not allow any further connections.

Here are the precautionary notes I have added to the wiki. For comment.

One last, *important production note*. Since old versions of the client will continue to grant access to the old database, you definitely do not want new clinical entries or clinical revisions to be split between two databases and the same goes for any importers at risk of continuing to import data into the old database. Accordingly, in preparation for migrating your *production* database,

* ensure that you have available suitably-configured copies of the client for the new production database * backup, and then insert a suitable logon banner into, the about- to-be-upgraded database * stop any and all importers, and point them to the about-to-be new database
   * upgrade the old database, resulting in a cloned "new" database
   * modify the logon banner of the new database
   * restart any and all importers
* depending if it is desired to keep the old database available, reconfigure it to not allow any further connections and/or remove or control the copies of the client that would point to it

reply via email to

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