Re: [Gnumed-devel] another suggestion

[Karsten Hilbert]

> Another issue is schema versioning ;  gnumed keeps changing the model 
> based on some rational refinement that extends over many
> months, without much recourse to experimental knowledge gained from 
> hooking a working application on it.

> I just started looking at a messaging application in java for clinical 
> applications, and they've got an interesting versioning system :
> they have sql scripts of the a particular starting version which is 
> meant to be installed first onto the database system.
> Then they have a component that inspects the tables and possible table 
> fields and come up with a version number.
> then they loop through a list of  versioning objects that have    
> methods to drop different parts of the schema in a particular order,
> e.g.  indexes, constraints, views, tables, and then  methods to add new 
> version  tables, constraints, views , indexes  ; and apply
> the versioning objects that have a number greater than the guessed 
> current version number , onto the backend schema.
This is how we will have to work post-release: Tag a release
state in CVS, branch devel from that, bug-fix in release only,
on next release write SQL change scripts to migrate from
latest-bugfixed-release to new-release.

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