Re: How to manage the versions of databases ?

josephmisko_at_noham.hotmail.com (Joseph Misko) wrote in <t88j73um60l8c_at_corp.supernews.com>:

>If you are modifying the structure of your databases every three months
>and releasing to your customers, you need to step back and do some
>longer-range analysis.
>Mapping out the complete goals and needs of your
>application will eliminate this management nightmare.

I'm sorry, but english isn't my native language, and I don't understand what you mean by speaking about "Mapping out the complete goals and needs". May you explain it in a more simple way please ?

>An application's
>data structure should change at most once every major version release
>(ideally, at most once per year--some never change).

But that's what we do ! Indeed, we release some version often.

>When you do have
>to modify the structure, write one single conversion routine and take
>that with you to all the sites, after you have tested it well on a
>complete data set.

That was our first idea, but we should have to do that between each version ! And we'd like to find an automatic way to do that.

Our other idea was to use 'Castor' : this is a framework that takes a db scheme in xml, generate the ddl for a relation db, the java classes to access the object, and the java classes to marshal/demarshal the objects between java and the RDBMS.

Then, with two different xml schemes, we would have get two sets of java classes. At this point, we must instanciate ALL the objects of the first xml scheme, and write a converter that instanciate the objects of the other version, and write them down to the new rdbms using the demarshaler of the other xml scheme.

Ok ?

I know it sounds weird, tough and long, but SO clean (object view is simple).

Maybe you know another way ?

-- 
Nicolas Ecarnot | E-mail: nicolas.ecarnot_at_bigfoot.com

The sum of CPU power and user brain power is a constant.