Play, Hibernate and Evolutions

What is often the case is that an application has two phases in its life cycle - initial development and post-production "maintenance". My experience is that often, all the big database changes happen in the first phase. Let yourself be flexible there by relying on Hibernate, then when you go to production, you take a schema dump, roll that on production with Evolutions, and manage your DDL manually from there.

In the second "phase" (I'm an agile guy, I hate the word ;-)), schema changes often include DML as well because you have to calculate initial values for new columns, etcetera. Also, you'll usually be spending more time on coding than on schema changes, so the whole manual experience becomes a bit less painful :).

(Having said that - I'd love a better integration between Evolutions and Play/Hibernate, like having the option to record the DDL that Hibernate spits out to the evolutions directory)

Well you ask a very good question. I struggled with this problem on grails, so I have not really a solution, but some thoughts. I will start with a comparison of Evolutions with Liquibase:

1. Liquibase is a matured solution, even if the plugin isn't under development any more, the underlying library is it. So I think it's an acceptable solution.
2. If you use Evolution you have one big disadvantage compared with liquibase: You must write your SQL directly, so the scripts depends on your database-system. Think abouts booleans and the representation in different databases. So you lost benefit Hibernate gives you.

Now to the general problem. I think you have to options:

1. Let Hibernate handle the database structure for you. Only in cases Hibernate can't do the job, you use liquibase or evolutions. Unfortunately you can run into some troubles if you have complicated update scenarios. How ever you win that your development is faster.
2. You ignore all DDL-Features from Hibernate and do everything with liquibase or evolutions. This is the most reliable and robust solution, but obviously you have much more work in development.

So what is my recommendation? I would try the following approach: Develop with an distributed version control system, like bzr or git. Then use feature-branches. Use for feature branches always the hibernate functionality. Before you merge the stuff into the trunk, create liquibase-script. These script can be generated by liquibase with some manual customizing). So you can develop a feature very quick and has in trunk always the robust solution 2. How ever be aware that this isn't a proofed approach in great project. I only tested this strategy with Hibernate and Liquibase on a small project - it works fine.

So would be great to get feedback.

Regarding having hibernate spit out the SQL to get you started to use Evolutions or Flyway, take a look at this: http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/toolsetguide.html#toolsetguide-s1-6

EDIT: I actually made a plugin to bootstrap your migration script. I think it might be useful to most of the people that come across this thread:http://web.ist.utl.pt/~joao.a.p.antunes/2014/08/09/play-2-2-x-jpa-hibernate-database-migration

Cheers!