Strategies for handling updates in existing JPA persistence classes

We are doin开发者_C百科g a project in which we have planned to use JPA Persistence. We think that once the project goes live, there is a small chance that changes in the data model might be required.

My query is that what are the different strategies available to handle such a change. Particularly I have following questions:

1. With updated JPA classes, what are the best practices to incorporate them in the existing database schema?

2. With JPA, are there any best practices to, archive old data, update database schema, and again migrate the database to the new schema?

3. What are the various kinds of changes (broadly speaking) that will make such a migration impossible?

In RHQ (http://rhq-project.org/ ) we have some dbutils that have a schema description in XML that serves to populate the initial schema on an empty database and then another xml file that registers changes to this base schema as individual "diffs" of DDL and DML statements.

Whenever a JPA class is changed (in a schema relevant way), both XML files are updated. On the next run of the installer, it will look at the existing database, gather its version and then play all the update steps from the version in the DB to the most current one.

This dbutils code is available in git.

There are other frameworks around like liquibase that can help you here.

You can also take a look at this framework: http://flywaydb.org

Advertised as: "The agile database migration framework for Java"

In my experience, migrations are not the problem (hibernate can do them automatically), but rollbacks are, if you are dealing with destructive changes. For example, if you remove a column, there's no way to rollback that change, unless you have the data from that column backed up somewhere. Best way do such backups probably depends on your DB vendor.