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

[James Busser]

On 18-Aug-08, at 5:53 PM, Rogerio Luz wrote:

If the DEVEL database will NEVER interfere with the production one (as Karsten suggested) I would think that there would be no problem working with both on the same live system. 

I think he was saying that upgrading from a production database *schema* to a newer database *schema* is not expected to cause a problem, for even if a problem is identified, it is likely to be found in triggers and indices etc and not in any thing whose fix would be destructive to any data.

However as I understand it if you were running GNUmed 8 as production and wished to have a second version of GNUmed running on the same server:

- if you "install" version 9, you will be destroying version 8, even though you intended to keep 8 for production while, at the same time, using 9 for testing

- if you "upgrade" version 8, a clone of 8 is created and imported into version 9

If you did not provide your staff with the clients and configurations that can connect to version 9, (unless the configuration files are the same and cause confusion -- Karsten might confirm) ---  then your staff would still be connecting to version 8 and making their additions and changes to the data in the version 8 database. That would allow you to carefully access version 9 with the new client and configuration, you would just have to be careful not to mistake v9 for your production database despite that it now has in it what looks like your real patient data because... well... it *is* your real patients' data, it is just missing the last few days and weeks of new information.

At the point when you are satisfied that version 9 works to your satisfaction, in theory you could re-upgrade version 8 (carrying forward all of your real data that you were careful was all entered in version 8) but I am not sure if the Upgrade script will allow version 8 to be upgraded to version 9 when version 9 is detected as already-existing. Maybe there should be a special procedure to delete version 9, if this is appropriate, before being able to (re)upgrade version 8.

Maybe a procedure to unambiguously test version 9 on the same server as production version 8 would be:

- upgrade version 8

- continue to use version 8 clients etc with v8 remaining "production"

- purge all data from version 9, rebootstrapping from the test data

- test version 9 while v8 continues in production

- 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.