Play, Hibernate and Evolutions_问答_开发者_运维开发者技术经验分享

I've no previous experience with tools like Liquibase and similar. Up to now the way I've usually managed deployment into production on apps using Hibernate was using manual SQL to modify the tables, as they were quite simple apps (the complex ones didn't use it...don't ask please :P).

I've wanted to use Evolutions in Play, but I see it clashes heavily with Hibernate in development, making it a pain and not a realistic option. In development Hibernate manages everything easily so there is no point on using Evolutions, but we wanted to keep the structure (files) to make it easier to migrate the app in production mode. But due to the clashes it doesn't seem worthy.

Liquibase had a Play module but it seems to have been discontinued since Evolutions was released (I wonder why, as I believe it would work wonder with Hibernate).

The question(s) would be:

How do you manage database migrations of apps in production?
What's the usual procedure/steps you use when your model changes between releases and you have to deploy to product开发者_JAVA百科ion?
Any specific tool or feature of Hibernate we are overlooking, or just old-faithful SQL Alter table and similar?
Focusing on Play Framework, how do you manage this?

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:

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.
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:

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.
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!