How to set up a deployable self-updating persistence with JPA and Hibernate

[Hubert Grzeskowiak]

Hi there,

I've only recently started using JPA and in my company we're having this line in the persistence.xml properties:
<property name="javax.persistence.schema-generation.database.action" value="create"/>
which is commented out as soon as the schema has been created.
This line then is supposed to update the schema as soon as something is changed on the entities:
<property name="hibernate.hbm2ddl.auto" value="update"/>

Is it possible with JPA to simply have one persistence.xml that does it all: Create schema if not existent and update if existing is not up to date?

[Roel De Nijs]

Hi Hubert Grzeskowiak,

First of all, a warm welcome to CodeRanch!

Hubert Grzeskowiak wrote:Is it possible with JPA to simply have one persistence.xml that does it all: Create schema if not existent and update if existing is not up to date?

It seems the creation of database schemas was finally standardized with JPA 2.1, but it seems there is no support to update an existing schema when it's not up to date.

Hope it helps!
Kind regards,
Roel

[Tim Holloway]

There's a distinction between what JPA supports and what Hibernate supports. Hibernate has long had this ability. Probably since before it added JPA features.

Personally, I prefer to use the offline utilities to do my schema mayhem. I'm a little too paranoid to want an application to possibly overhaul a schema that other apps might then get in a fight re-overhauling it, for example. But it is convenient, especially when you want a software update that has its accompanying schema create/update functions bundled in a single DBA-free deployable.

[Roel De Nijs]

Tim Holloway wrote:But it is convenient, especially when you want a software update that has its accompanying schema create/update functions bundled in a single DBA-free deployable.

At one of the customers I worked for, we use Liquibase to have this functionality. Liquibase is an open source database-independent library for tracking, managing and applying database schema changes. So you define a set of database changes in e.g. XML format and then you run liquibase update to execute the database changes (can be on demand or automated as part of e.g. your build process). The files containing the database changes can of course be committed to source control as well.

[Tim Holloway]

If memory serves, Liquibase also can capture and revert data snapshots and a shop in my home town was using it for that.

[Hubert Grzeskowiak]

Thanks for the answers. I will definately look into Liquibase. From the first look, it can't generate diffs based on changes in your entity classes, can it?

This is just some luxus I'm used from Django (Python web framework). Django compares existing schema or migrations (not sure) with the current model code and generates diffs, usually prompting you if it can't know how the mapping looks exactly. In a second optional step you can change the migrations which are basically sort of JSON IIRC. If you then run the last step, the database is migrated for you from all saved migration files (usually one per commit).

Thais said, I'll look deeper into Hibernate and Liquibase if they support something alike.

[Tim Holloway]

Liquibase isn't connected to Java. It works directly against the database.

If you're generating/updating the database schema by using JPA schema options against updated entity class definitions, then you'd run the Java code, which would update the actual database, then run Liquibase to capture what had been done.

[Roel De Nijs]

Hubert Grzeskowiak wrote:From the first look, it can't generate diffs based on changes in your entity classes, can it?

You are correct! You have to write the queries yourself and Liquibase will execute them. It is definitely not a Java Persistence provider like Hibernate.

Hubert Grzeskowiak wrote:Thais said, I'll look deeper into Hibernate and Liquibase if they support something alike.

Honestly I have never used Hibernate's capabilities of generating the database schema changes based on the entity model. I have always written the required SQL statements to perform the necessary changes. Probably a bit too skeptical (doubtful) if Hibernate (or any other JPA provider) won't be messing up the database schema and do more harm than good And I really like writing SQL statements, so I don't allow any JPA provider to deprive me from all that fun