I have no previous knowledge about tools like Liquibase and other alike. So far the way in which I have usually handled deployment into production on applications using Hibernate was using manual SQL to change the tables, because they were fairly simple applications (the complex ones did not utilize it...do not request please :P).

I have desired to use Evolutions in Play, however i view it clashes heavily with Hibernate in development, which makes it a discomfort and never an authentic option. In development Hibernate handles everything easily so there's no reason on using Evolutions, but we desired to keep your structure (files) to really make it simpler emigrate the application being produced mode. But because of the clashes it does not appear worthy.

Liquibase were built with a Play module however it appears to possess been stopped since Evolutions was launched (I question why, when i accept is as true works question with Hibernate).

The question(s) could be:

  • How can you manage database migrations of applications being produced?
  • What is the usual procedure/steps you utilize whenever your model changes between releases and you've got to deploy to production?
  • Any sort of tool or feature of Hibernate we're looking over, or simply old-faithful SQL Alter table and other alike?
  • Concentrating on Play Framework, how can you manage this?

You request an excellent question. I battled with this particular problem on grails, and so i haven't a real solution, however, many ideas. I'll begin with an evaluation of Evolutions with Liquibase:

  1. Liquibase is really a matured solution, even when the wordpress plugin is not under development anymore, the actual library could it be. And So I think this is an acceptable solution.
  2. If you are using Evolution you've one large disadvantage in comparison with liquibase: You have to write your SQL directly, therefore the scripts is dependent in your database-system. Think abouts booleans and also the representation in various databases. Which means you lost benefit Hibernate provides you with.

How to the overall problem. I believe you need to options:

  1. Let Hibernate handle the database structure for you personally. Only in the event Hibernate can't get the job done, you utilize liquibase or evolutions. Regrettably you are able to encounter some troubles for those who have complicated update situations. How ever won by you that the development is faster.
  2. You ignore all DDL-Features from Hibernate and fit everything in with liquibase or evolutions. This is actually the most dependable and robust solution, but clearly you've a lot more operate in development.

What exactly is my recommendation? I'd try the next approach: Develop by having an distributed version control system, like bzr. Then use feature-branches. Use for feature branches always the hibernate functionality. Before you decide to merge the stuff in to the trunk, create liquibase-script. These script could be produced by liquibase with a few manual designing). So that you can create a feature extremely swift and it has in trunk always the robust solution 2. How ever remember that this is not a proofed approach. I only examined Hibernate plus some manual SQL-scripts and was unhappy by using it.

So could be great to obtain feedback.

What's frequently the situation is the fact that a credit card applicatoin has two phases in the existence cycle - initial development and publish-production "maintenance". My experience is the fact that frequently, all of the large database changes take place in the very first phase. Let yourself be flexible there by depending on Hibernate, then when you attend production, you are taking a schema dump, roll that on production with Evolutions, and manage your DDL by hand after that.

Within the second "phase" (I am an agile guy, I personally don't like the term -)), schema changes frequently include DML too because you need to calculate initial values for brand new posts, etcetera. Also, you'll usually be investing additional time on coding than you are on schema changes, therefore the whole manual experience becomes a little less painful :).

(With that said - I'd love a much better integration between Evolutions and Play/Hibernate, like getting the choice to record the DDL that Hibernate spits to the evolutions directory)