Hacking on GraphHopper - a Java road routing engine. Peter has posted 62 posts at DZone. You can read more from them at their website. View Full User Profile

Simple Database Migration in Java

12.24.2009
| 7638 views |
  • submit to reddit

As I started with Rails development I discovered the very neat feature of database migrations. For me this was the main advantage of using Rails compared to a pure Java solution.

In our Rails application this works without any problems: you can change the database schema as well as migrating the data itself via ruby.

I needed a similar feature at that time in Java and discovered Liquibase, which was relative easy to use and stable. But it has (in my opinion) one major drawback that you have to use xml and for your data migration you even have to use pure SQL. Then you’ll run fast into some issues (e.g. this). But okay, there is also one advantage over the Rails-mechanism: you don’t need to specify the rollback statement (if it is not pure SQL) – liquibase knows from the migration command which revert command it should use.

If you use Hibernate one could stick with SchemaUpdate, but several things don’t work properly with that approach.

Another idea would be to export objects from version 1 and import them into version 2 directly within your application logic e.g. with Groovy … or should I give DMT I try?

Now I thought that Grails could solve this issue better for Java, but to my knowledge (‘Automatic Database Migration’) there is not such a mature migration concept within Grails like in Rails. The Liquibase plugin (grails install-plugin liquibase) or the outdated (?) dbmigrate plugin (grails install-plugin dbmigrate) can solve this as well as autobase, which is based on liquibase too. Does somebody has experiences with that? Here is a mini comparison.

Today I discovered migrate4j, which seems to be the best tool I found so far for pure Java. Another option would be to use JRuby with Rails or simply rails, but this would be a bit of an architecture overkill for the most people, I fear.

Other choices might be:

Do you know other (better?) solutions? How do you do db migrations?

From http://karussell.wordpress.com/

Published at DZone with permission of its author, Peter Karussell.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Vladimir Vilinski replied on Sun, 2009/12/27 - 5:09am

Hi Peter, nice to meet you again here, at dzone.

You have forgotten to say, that liquibase tries to run each change set in a single transaction. 

Liquibase has many other useful features like: db comparison (also against hibernate mapping) and generation of change logs/documentation.

Nathan Voxland replied on Sun, 2009/12/27 - 2:44pm

If you like liquibase except for the XML format, version 2.0 has been refactored to support multiple changelog file formats.

XML is the only version currently supported out of the box, but you can create create your own ChangeLogParser to read and/or write changelogs in any format you like.

Gautam Pandya replied on Mon, 2009/12/28 - 1:41pm

I would suggest to have a look at iBATIS 3.0 Schema Migrations too. Coming straight out of a project where Liquibase was used, I am very happy seeing this iBATIS tool. The advantages are- no xml - only sql, status reporting on the database state, version control, easy to use, easy install... http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/doc/en/iBATIS-3-Migrations.pdf

Gautam Pandya replied on Mon, 2009/12/28 - 1:42pm

I would suggest to have a look at iBATIS 3.0 Schema Migrations too. Coming straight out of a project where Liquibase was used, I am very happy seeing this iBATIS tool. The advantages are- no xml - only sql, status reporting on the database state, version control, easy to use, easy install... http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/doc/en/iBATIS-3-Migrations.pdf

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.