views:

91

answers:

4

Aloha,

I'm currently working on a desktop application using JPA/Hibernate to persist data in a H2 database. I'm curious what my options are if I need to make changes to the database schema in the future for some reason. Maybe I'll have to introduce new entities, remove them or just change the types of properties in an entity.

  • Is there support in JPA/Hibernate to do this?
  • Would I have to manually script a solution?

Thanks

A: 

Which aspect of the change troubles you? In case you need to change the database schema, you will basically have to update your model and mappings according to that. Migrating the data is not within the scope of Hibernate/JPA.

vstoyanov
Nothing troubles me, I'm just asking out of interest :)
willcodejavaforfood
+4  A: 

I usually let Hibernate generate the DDL during development and then create a manual SQL migration script when deploying to the test server (which I later use for UAT and live servers as well).

The DDL generation in Hibernate does not offer support for data migration at all, if you only do as much as adding a non-null field, DDL generation cannot help you.

I have yet to find any truely useful migration abstraction to help with this.

There are a number of libraries (have a look at this SO question for examples), but when you're doing something like splitting an existing entity into a hierarchy using joined inheritance, you're always back to plain SQL.

Henning
+1 for being very informative :)
willcodejavaforfood
+1  A: 

There are two options:

  • db-to-hibernate - mirror DB changes to your entities manually. This means your DB is "leading"
  • hibernate-to-db - either use hibernate.hbm2ddl=auto, or manually change the DB after changing your entity - here your object model is "leading"
Bozho
What kind of changes can hibernate.hbm2ddl=auto cope with without screwing up my DB? :)
willcodejavaforfood
almost any. Except for drop columns, I guess, where you'll have to drop them yourself.
Bozho
Do *not* use `hbm2ddl=auto` in a production setting, you are begging for trouble if you do.
matt b
@matt b - Care to elaborate? :)
willcodejavaforfood
+1  A: 

Maybe I'll have to introduce new entities, remove them or just change the types of properties in an entity.

I don't have any experience with it but Liquibase provides some Hibernate Integration and can compare your mappings against a database and generate the appropriate change log:

The LiquiBase-Hibernate integration records the database changes required by your current Hibernate mapping to a change log file which you can then inspect and modify as needed before executing.

Still looking for an opportunity to play with it and find some answers to my pending questions:

  • does it work when using annotations?
  • does it require an hibernate.cfg.xml file (although this wouldn't be a big impediment)?

Update: Ok, both questions are covered by Nathan Voxland in this response and the answers are:

  • yes it works when using annotations
  • yes it requires an hibernate.cfg.xml (for now)
Pascal Thivent
@Pascal Thivent - Wheeeeeee :)
willcodejavaforfood
Cool, I don't actually have a hibernate mapping file, just a persistence.xml
willcodejavaforfood
@willcodejavaforfood Yeah, same here. But as I wrote, I'm not sure it can deal with a persistence.xml (I was thinking about generating an hibernate.cfg.xml to play with it if required). Maybe open another question and [Nathan Voxland](http://stackoverflow.com/users/45756/nathan-voxland) (the creator of Liquibase) will show up :)
Pascal Thivent
@Pascal Thivent - According to this [question](http://stackoverflow.com/questions/776787/hibernate-using-jpa-annotated-entities-and-liquibase you do need) you need a hibernate.cfg.xml but you are right that would not be a big problem
willcodejavaforfood
@willcodejavaforfood Thanks, the perfect confirmation!
Pascal Thivent