Re: [Gnumed-devel] Re: Development testing on Production (?) servers -- was 0.3-rc4 released

[James Busser]

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 because there is nothing to stop or even warn anybody who would be using the "old" client against entering new data into the now-deprecated database.

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.

Would it be safer if the final step of the bootstrap, assuming that it had encountered no problems, to rename the database that had been updated for example

rename v8 v8arch

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

??

On 18-Aug-08, at 6:21 PM, James Busser wrote:

- when ready to move production up to v9:

- drop v9 database

- reupgrade version 8

- provide and configure v9 clients to the staff

I am not sure about the role of keeping v8 database clients except if the v9 database should run into problems, it is possible that v8 could still be accessible and helpful while waiting for v9 to be rebuilt form the last backup. I don't know how realistic that is... meaning whether the problem that would corrupt or make unavailable the v9 database would be likely to also make unavailable the v8 database.