Database schema changes: migration how to

[Max Ischenko <ma...@malva.ua>]

Hi,

I'm evaluating possibility on using an O-R mapping tool in my current
project.  I've read tutorial on torque and similar other O-R mapping tools and
wonder how the migration is managed.

Suppose, I've created a book database scheme, generate sql/java code and
deploy it. Some time later when a lot of data 's been filled into DB I
discovered that I had to add/change/remove some properties on the Book
class. I could tweak the schema file and re-create sql/java code but how
one typically perform migration data to new db scheme.

An elaborate answer or pointers to relevant Web resources are greatly
appreciated.


-- 
Regards, max.

Re: Database schema changes: migration how to

[Eric Emminger <er...@ericemminger.com>]

Jan

> This sounds strange to me. I think you can change the business object
> (the non-Peer objects) and add methods to them or fields that need not
> be stored in the database. The moment you have the need for
> fields/properties that you want to store in the database, you should
> change your scheme and recreate the Peer objects (the bussiness objects
> are not touched by regeneration, so changes there remain.

Yes, you can change both the extended business object and even the 
extended Peer. Only the Base* classes are overwritten by Torque when you 
generate the model. So, yes, you could just manually change the Torque 
schema and regenerate the model.

> So I am wondering: if you add those properties to your objects, do you
> also adapt the peer classes?

No, you don't *have* to do anything to the Peer classes, unless you want 
to extend their function.

> Ok, i can imagine that if you add fields according to some kind of
> naming convention and then regenerate this into the xml-schema. But then
> again, is this really a big thing. You have to remember the properties
> you add and add them to the xml scheme.

Sure, this is simple for simple changes. But what if you refactor your 
model, making significant changes, such as breaking out a set of 
properties into a one-to-many relationship? When you deploy the changed 
app, you need to change all the existing data in the database. That 
makes it more complex.

Eric

Re: Database schema changes: migration how to

[Jan Marten Visser <ja...@virgil.nl>]

Eric Emminger wrote:
> 
> Jan
> 
> > I guess I am missing the point here, if you change a relational database
> > scheme, e.g. add columns, you introduce new data. It is off course
> > impossible to generate new data by means of Torque or any tool.
> > I guess you are referring to other changes.
> >
> > Could you give an example of such a change which could be supported by
> > tools because I think I am missing the point.
> 
> Well, I was assuming, perhaps incorrectly, the following example.
> 
> 1. Deploy a release of your application.
> 2. Continue developing your app, including adding, removing, and/or
> changing some properties in your objects. This would require the
> database schema to change to store the objects.

This sounds strange to me. I think you can change the business object
(the non-Peer objects) and add methods to them or fields that need not
be stored in the database. The moment you have the need for
fields/properties that you want to store in the database, you should
change your scheme and recreate the Peer objects (the bussiness objects
are not touched by regeneration, so changes there remain.

So I am wondering: if you add those properties to your objects, do you
also adapt the peer classes?



> 3. Deploy new release of your app with changes from step 2.
> 4. Instruct tool to automatically migrate data from app in step 1 to app
> in step 3.

Ok, i can imagine that if you add fields according to some kind of
naming convention and then regenerate this into the xml-schema. But then
again, is this really a big thing. You have to remember the properties
you add and add them to the xml scheme.



> 
> Theoretically, the tool could do this if it were "aware" of the changes.
> I've used some tools in the past that come close if not accomplish this.
> 
> Was that example useful?
> 
> Eric
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org

Re: Database schema changes: migration how to

[Eric Emminger <er...@ericemminger.com>]

Jan

> I guess I am missing the point here, if you change a relational database
> scheme, e.g. add columns, you introduce new data. It is off course
> impossible to generate new data by means of Torque or any tool.
> I guess you are referring to other changes.
> 
> Could you give an example of such a change which could be supported by
> tools because I think I am missing the point.

Well, I was assuming, perhaps incorrectly, the following example.

1. Deploy a release of your application.
2. Continue developing your app, including adding, removing, and/or 
changing some properties in your objects. This would require the 
database schema to change to store the objects.
3. Deploy new release of your app with changes from step 2.
4. Instruct tool to automatically migrate data from app in step 1 to app 
in step 3.

Theoretically, the tool could do this if it were "aware" of the changes. 
I've used some tools in the past that come close if not accomplish this.

Was that example useful?

Eric

Re: Database schema changes: migration how to

[Jan Marten Visser <ja...@virgil.nl>]

Eric Emminger wrote:
> 
> Max
> 
> > I'm evaluating possibility on using an O-R mapping tool in my current
> > project.  I've read tutorial on torque and similar other O-R mapping tools and
> > wonder how the migration is managed.
> >
> > Suppose, I've created a book database scheme, generate sql/java code and
> > deploy it. Some time later when a lot of data 's been filled into DB I
> > discovered that I had to add/change/remove some properties on the Book
> > class. I could tweak the schema file and re-create sql/java code but how
> > one typically perform migration data to new db scheme.
> >
> > An elaborate answer or pointers to relevant Web resources are greatly
> > appreciated.
> 
> As far as I know, no OR mapping tool, including Torque, has an easy way
> to migrate data between changed models. Migration usually involves
> either database-specific SQL code to change the existing database, or
> creating a new database and moving the data.
> 
> If you know or find anything that would change the above information,
> please tell us, or at least me. :)

I guess I am missing the point here, if you change a relational database
scheme, e.g. add columns, you introduce new data. It is off course
impossible to generate new data by means of Torque or any tool.
I guess you are referring to other changes.

Could you give an example of such a change which could be supported by
tools because I think I am missing the point.

Re: Database schema changes: migration how to

[Eric Emminger <er...@ericemminger.com>]

Max

> I'm evaluating possibility on using an O-R mapping tool in my current
> project.  I've read tutorial on torque and similar other O-R mapping tools and
> wonder how the migration is managed.
> 
> Suppose, I've created a book database scheme, generate sql/java code and
> deploy it. Some time later when a lot of data 's been filled into DB I
> discovered that I had to add/change/remove some properties on the Book
> class. I could tweak the schema file and re-create sql/java code but how
> one typically perform migration data to new db scheme.
> 
> An elaborate answer or pointers to relevant Web resources are greatly
> appreciated.

As far as I know, no OR mapping tool, including Torque, has an easy way 
to migrate data between changed models. Migration usually involves 
either database-specific SQL code to change the existing database, or 
creating a new database and moving the data.

If you'd prefer the latter, you can search the archives for import, 
export, migration, transformation, etc. I use this approach in 
development. In production, I would choose an approach that would be 
appropriate for the changes. But, hey, this is just what I do.

If you know or find anything that would change the above information, 
please tell us, or at least me. :)

Eric