Managing Unmapped Tables with Hibernate

Written by RyanStewart

February 3rd, 2010 at 11:30 pm

Posted in Uncategorized

Tagged with

With one comment

There’s an underused feature of Hibernate that I’ve been using recently called “auxiliary database objects“. With these guys, you can finally let Hibernate manage all of your schema creation and deletion. No more using Hibernate to generate mapped tables and then coming behind with another tool to finish the job.

A good example of where this is useful is in the fairly common case of using Quartz for scheduling with a JDBC job store. Quartz provides a SQL script for generating its tables. Before auxiliary database objects, the most common way to get the Quartz tables into the database was to include a separate *.sql file in your build and run it using Ant’s sql task or some other SQL executor. Setting it up this way means there are two steps to either creating or dropping your schema: the Hibernate schema export and the Ant task. That ties this mechanism specifically to your build, eliminating a very useful feature of Hibernate.

With auxiliary database objects, you can include the Quartz create and drop scripts directly in your Hibernate mappings and have Hibernate run those scripts along with its normal schema export. Then there’s only one step to creating and dropping your schema, and more importantly, Hibernate is completely in control of the schema. This gives you the immense benefit of being able to set the SessionFactory’s “hbm2ddl.auto” property to “create” and run an in-memory database–like the awesome H2 database–for development and unit testing, and the schema will be generated for you on startup. This is what you lose if you have scripts outside of Hibernate.

Auxiliary database objects have actually been around for a few years, but it only made it into a general availability release a year and a half ago with version 3.2.6.GA. Below are a couple of simple examples on how to use them.

Besides Quartz tables, I’ve used auxiliary database objects to make a fake “dual” table. It’s common to use the “select * from dual” query on Oracle databases as a validation query for your connection pool. When you run a different database for development, like H2 or MySQL, you’ll have to manually add a dual table so that your validation queries won’t fail. Here are the two ways that you can do that using Hibernate’s auxiliary database objects:

First, you can embed the SQL directly in the mapping file:

<hibernate-mapping>
    <database-object>
        <create>
            create table dual (x int);
        </create>
        <drop>
            drop table dual;
        </drop>
        <dialect-scope name="org.hibernate.dialect..." />
    </database-object>
</hibernate-mapping>

Note that you can have zero to many of the dialect-scope elements, indicating what database platforms this database object applies to. Listing zero dialects means apply to all databases.

The second way to do it is to implement the AuxiliaryDatabaseObject interface. To make it simple, use the AbstractAuxiliaryDatabaseObject subclass:

public class SampleObject extends AbstractAuxiliaryDatabaseObject {
    public String sqlCreateString(...) {
        return "create table dual (x int)";
    }

    public String sqlDropString(...) {
        return "drop table dual";
    }
}

Then you have to specify your class in your mapping file, like so:

<database-object>
    <definition class="rds.hibernate.AuxDBObjectTest" />
    <dialect-scope name="org.hibernate.dialect..." />
</database-object>

The examples should be pretty self explanatory. Create statements are run after Hibernate’s own generated create statements, and drop statements are run after Hibernate’s generated drop statements. I’ll make one additional recommendation: while it’s technically possible to put multiple SQL statements separated by semicolons in a single create or drop block, it’s best to only put one. There are two reasons for this. First, multiple statements in a single block won’t work with Oracle, so if any of your target environments are Oracle, that’s right out. The second reason is that Hibernate runs each create and/or drop using one JDBC Statement, so if you pack 100 create statements into one create block, and one of them fails, then none of the other 99 will take affect, either. If, on the other hand, you use one statement per block, you guarantee that all statements will run, and only the ones that fail will not take effect.

That’s all! It’s very handy to have all your extra SQL managed by Hibernate. All you have to do is point Hibernate at a database, tell it to create your schema, and all your tables, views, stored procedures, etc. will appear.

Share

Related Posts

Comments

One Response to “Managing Unmapped Tables with Hibernate”

  1. Eric Millinder on February 18th, 2010 10:48 pm

    These are also handy when your classes are mapped to views.

Leave a Reply