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

[Karsten Hilbert]

On Mon, Aug 18, 2008 at 06:21:42PM -0700, James Busser wrote:

> 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.
Note that this applies only *now*. I am confident in the
above *currently* as regards the v8 to v9 upgrade.

Technically there should *never* be a required change
destructive to any data. However, there will be changes
*modifying* data -- but not in v8 - v9 anymore, I'm pretty
sure.

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

> - if you "upgrade" version 8, a clone of 8 is created and imported into 
> version 9
v8 is cloned and the *transformed into* v9

> 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
They are the same *except* for the database name.

> 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,
Correct. That's the idea.

> you 
> would just have to be careful not to mistake v9 for your production 
> database

It is a) not easy and b) not possible because

a) in real deployments the database logon message could/should
   give some indication as to which database one is connecting to,
   that is the reason why this message exists

b) the client actively verifies the database version it connects
   to and refuses to connect to a database it is not intended
   to work with (unless --override-schema-check is given on the
   command line and then, well, you are on your own)

> 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. 
It will, yes. The decision about that is configurable in the
upgrade configuration file.

> 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
No purging. Just drop any pre-existing v9 and upgrade v8 to
v9 (this will keep v8 untouched which is the whole point of
the exercise).

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

Correct.

> I am not sure about the role of keeping v8 database clients
It may be useful to keep them "for a while" after switching
to v9 just in case.

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

It needn't be corruption but rather "something else" from
the vast array of potential IT problems. The occur whenever
and however one expects them the least. I have seen to much
of such bull*t

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