Running DB migration prior to jpa initialization

[anilarora]

We are running into an issue with Hibernate initialization where our database schema is out of date. So, we want to run some DB migration script on the fly using http://code.google.com/p/flyway/ which needs to get invoked after the DB subsystem is up, but before Hibernate/JPA initialization occurs.

First question, has anyone come up with a solution that is clean and performant?

I was thinking that I could write a JBoss AS extension module to do this and have some sort of deployment mechanism to call the flyway code.  The question was how to ensure the ordering of the deployment initialization so that my code gets called before JPA is called, but after the databases have been deployed as I'll need to access the datasource via JNDI or an API.

Thanks!

[smarlow]

Would you package the migration script with the application?

You might want to follow the JPA 2.1 specification which introduces a few different ways to accomplish this (for EE7).  See section 9.4 Schema Generation. 

[anilarora]

Unfortunately, I must remain on Hibernate 3.6.10 and I don't want to rock the boat on changing that at the moment.

Yes, the classes/script files would be packaged with the application. I'd probably create some deployment descriptor special for this case to make this happen.

[smarlow]

Lately, I'm thinking that a "wildfly.jpa.migration" (or something like that) persistence unit hint, could be used to trigger the database migration before the persistence unit service creates the entity manager factory.  When I have time to work on it, I'll  associate a git branch with WFLY-1186 for us to use for this feature. 

http://stackoverflow.com/questions/11071821/cdi-extension-for-flyway mentions some current solutions that could be used with Hibernate 4.x, in case anyone is interested in trying that now.

With "wildfly.jpa.migration", we could use the  http://flywaydb.org project (if available) or the JPA 2.1 schema generation support (see comments in WFLY-1186).  Why allow two methods?  Because JPA 1.0/2.0 persistence providers don't have the schema generation support and flywaydb is more flexible in other ways (the optional flywaydb java based migration gives more flexibilty).

Scott