have you tried setting the hbm2ddl to update, it creates the schema if it does not exist and updates if it (if any updates are needed). Beware that it (in my experience) only adds to the schema and does not remove from the schema.
What I'd like to do is just to validate the schema at each JBoss AS startup.
Usually updates required to perform additional tasks (such as SQL statements to initialize new fields). I don't want to redo an update at each boot of JBoss.
Problem is just o be able to get the SQL scipt generated to perform an upadte or a DB creation to package it properly with all my admin tasks required to install or update my application.
If you're just looking for the SQL that was executed by Hibernate to make the tables, you can configure Log4J:
<!-- Show SQL Logs for Hibernate Schema Export --> <category name="org.hibernate.tool.hbm2ddl.SchemaExport"> <priority value="DEBUG" /> </category> <category name="org.hibernate.tool.hbm2ddl.SchemaUpdate"> <priority value="DEBUG" /> </category>
Simple but efficient solution !
Simple usually is. :)
In my environment I'm currently using a little EJB3 JMX Pojo called a "DatabaseBootstrapService". Its responsibility:
* Ensure the necessary schemas exist, and if not, creates 'em
* Ensure the necessary DB users exist, and if not, creates 'em.
* Creates the necessary tables.
* Populates required data for the system to work.
All this is done via execution of SQL Files I place in $JBOSS_HOME/server/[serverName]/sql. In local development and staging environments, HBM2DDL is set to autogen (create-drop for local and update for stage). However, in production, I don't want Hibernate ever mucking with the schema. So I set the Service to fire off the SQL scripts, which are really just preapproved executions of the Hibernate HBM2DDL from the stage environment logs.
...and this is my solution for DB migration between versions as well. Build locally, test on Stage, and once I'm sure that the SQL fired by Hibernate (and any other operations I need to do) are square, I create SQL Scripts for them and fire from the JMX console so I can take advantage of the transaction it provides.
What are some other solutions out there for migration/DB population?