Hibernate 3 Formulas

Hibernate and Spring are two outstanding open source frameworks gaining usage in more and more J2EE applications. Though targeting very different problem spaces, they share one key feature: dependency injection. Spring helps sort out dependencies among objects before returning these objects to a client, and thus reduces much coding inside the client. Hibernate specializes in sorting out dependencies presented by a data model before returning an integral object model to a client. When using JDBC directly to map a data model into an object model, we normally need to write a large amount of code to build an object model. Hibernate eliminates most of this coding work.

Hibernate 2.x provides basic table-to-object mapping, normal association mapping (including one-to-one, one-to-many, and many-to-many relationships), polymorphism mapping, etc. Hibernate 3.x pushes this to another level by enhancing mapping flexibility with formula, filter, subselect, etc., which provide fine-grained interpretation features.

In this article, we will show how various features of formula can help in model conversion. Before Hibernate 3.x, the formula attribute could only appear in a property element. While you can still do that, Hibernate 3.x provides a formula attribute or element (both are virtually equivalent in terms of formula usage) that can be used in many elements, including discriminator, many-to-one, one-to-one, element, many-to-many, map-key, map-key-many-to-many, and property. This adds much flexibility to object-relational (O-R) mapping, and thus allows further fine-grained interpretation of complex data models.

There are basically two scenarios where using formula is necessary:

1. Cases where a formula evaluation result is needed. Using formula with the elements discriminator, element, map-key, map-key-many-to-many, and property falls into this category.
2. Cases where a formula is needed for joining purposes. Using formula with the elements many-to-one, one-to-one, and many-to-many falls into this category.

Category 1: Getting an Evaluation Result from a formula

Discriminator

In real data schema, there are often cases where one table is used to describe another table. formula can help provide flexible polymorphism in O-R mapping.

In the example shown in Figure 1, there are two tables: Product and ProductRelease. Each product record has a ProductReleaseID referencing its corresponding product release record, including product release name, type, release date, etc.

Figure 1. Product and product release data model

One interesting attribute in the ProductRelease table is SubProductAllowable, which can have a value of either 0 or 1. A value of 1 means sub-products are allowed under any product of this product release, while 0 means no sub-product is allowed. For example, some products are assembled from multiple sub-products, and some products are solely units unto themselves.

Figure 2 shows an object model interpreted from this data model. The Nested interface defines the getSubProducts and setSubProducts methods. The class NestedProduct extends the base class Product and fulfills the Nested interface, as well. Whether a product data record should be a Product or NestedProduct depends on the value of SubProductAllowable of its corresponding product release record.

Figure 2. Product and product release object domain model

In order to achieve this model conversion, we use a Hibernate 3.x mapping, as follows:

<hibernate-mapping>

  <class name="Product" 

        discriminator-value="0"  lazy="false">

    <id name="id" type="long"/>       

    <discriminator 

        formula="(select pr.SubProductAllowable 

                from ProductRelease pr 

                where pr.productReleaseID=

                        productReleaseID)"

        type="integer" />

    <subclass  name="NestedProduct"  

        discriminator-value="1"/>

  </class>

</hibernate-mapping>