Update Handling Strategies in Existing JPA Retention Classes

Question

We are doing a project in which we plan to use the resilience of JPA. We believe that after the project is operational, there is little chance that changes to the data model may be required.

My request is what different strategies are available to handle such a change. In particular, I have the following questions:

• With updated JPA classes, what are the best methods for incorporating them into an existing database schema?

• With JPA, are there any recommendations, archive old data, update the database schema, and migrate the database to the new schema again?

• What are the different kinds of changes (in a broad sense) that will make such migration impossible?

Answer 1

In RHQ ( http://rhq-project.org/ ) we have some dbutils that have a schema description in XML, which serves to populate the initial schema with an empty database, and then another XML file that records changes to this basic schema as separate "differences" of DDL and DML operators.

Whenever the JPA class changes (in the appropriate schema), both XML files are updated. At the next launch of the installer, he will search for the existing database, collect its version and then play all the stages of updating from the version in the database to the latest.

This dbutils code is available in git .

There are other frameworks like liquibase that can help you.

Answer 2

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

Advertised as: "Advanced Database Migration Environment for Java"

In my experience, migration is not a problem (hibernation can do this automatically), but rollbacks if you are dealing with destructive changes. For example, if you delete a column, there is no way to undo this change unless you have data from that column. The best way to do such backups probably depends on your database provider.