[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: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: Development testing on Production (?) servers -- was 0.3-rc4 released
Date: Tue, 19 Aug 2008 15:48:24 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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.

0.3 is intended to support all backend profile data to be
definable in the system-wide config file. A package
maintainer should be able to control the content of that
file during package upgrade. Thus, when the client package
is upgraded it may be sufficient to upgrade just one config

> or even warn anybody who would be using the "old" client 
What makes you think that ?

> Even if the praxis IT-support person is able to get access to all of the 
> on-site computers (and all of the user accounts within them, in case 
> there are copies of the client within users' individual /home/  
> directories) there can be copies temporarily inaccessible to the IT  
> support person, such as on the laptops or home computers of some of the 
> clinicians.
This is an inherent problem.

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.

> This would protect the old clients from being able to access the old  
> database in the mistaken belief that they are still accessing the "live" 
> database. Would a good solution be to build into the config file a login 
> selection named
>       GNUmed archive
> that would only work with a deprecated version name. For example the  
> client that by default expects the current (devel or production) version 
> to be v9 would include a config for version
>       v8arch

This is not possible. A client written to work with v9 will
not reliably work with v8.

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]