Getting Started with Hibernate

Hibernate is an Object Relational Mapping (ORM) tool. It manages the persistence of java objects in a relational database. The idea is that a programmer should be able to design his business objects as standard Java objects with very little interference from the problems of making these objects persist in a database. Together with a little help from the programmer, Hibernate saves the objects into the database, retrieves them when needed and supports queries on the database written in a form similar to SQL but which refers to objects and object properties instead of tables and column names. The end result is that the code that needs to be written to interact with the database is considerably shorter and simpler.

This document is intended to cover only the basics of Hibernate: i.e., do things the way it is described here until you have outgrown it. Hence many features are only referred to in passing or not mentioned at all. The full reference documentation and a great deal of other important information is available on line at http://www.hibernate.org/5.html:Hibernate On Line Documentation. However, for serious users of Hibernate, a thorough study of [BK05] is highly recommended.

Important

The books currently in print all discuss a version of Hibernate earlier than 3.0. However, Hibernate has moved on and the latest version as of 23 January 2006, is 3.1.1. There were incompatible changes between versions 2 and 3, so when reading the text books, you should have beside you the migration guide: http://www.hibernate.org/250.html:Hibernate Migration Guide The differences are, generally, small, but enough to stop even simple hibernate examples from working. Critically, all the hibernate classes (and log4j logger names) are now org.hibernate... instead of the old net.sf.hibernate.... Some of the Session methods for query execution (find(), iterate(), filter(), and delete()) have been not just deprecated, but moved into a different package (presumably to encourage programmers to abandon them). To replace them, you should use createQuery for all queries, and DELETE HQL queries for bulk deletions — session.delete(object) is still okay for deleting a single object. Similarly, saveOrUpdateCopy() (use merge() instead) has gone the same way. However, if you just want to get an example from a book working quickly, you can still use the deprecated methods simply by replacing your org.hibernate.Session objects with org.hibernate.classic.Session ones. Finally, in the hbm.xml files, the dtd has changed from http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd to http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd The set of cascade options has changed to bring Hibernate into alignment with the EJB3 standard.

Here we provide a fully working, but very simple, example application using Hibernate. The example is based on some fragments that appear in chapter 2 of [BK05]. The files necessary are:

The basic pattern of database interactions via Hibernate is visible in the Main.java file above.

The Hibernate Object Life Cycle

Given a pair of (persistent) objects of the same class, we now have three concepts of identity to consider.

The rule for Hibernate, is that if, within a single Session, you request two objects which have the same database identifier, then you will get references to the same actual objects. It accomplishes this by using a cache for persistent objects. Anytime you request, in any way, a persistent object, Hibernate first checks in the cache for it and, only if it can't find it there, will Hibernate actually execute a query to get the data from the database and create an object for it. Incidentally, this means that you can use Java Identity (i.e. ==) to test persistent objects for identity, even if you would normally need to use the equals().

Since the programmer can define the equals(), it is important not to use the id field in that definition if the id field is a surrogate key. This is because, if the object uses a generated identifier value for its id, or if at least part of its id is a reference to another object (i.e. a foreign key), then Hibernate only sets the field the first time it saves the object to the database. Hence, for example, if you add the object to some set or map collection, then saving the object will result in its identity changing, and part of the rules about using the set collection class is that the contained object's identity must not change while it is in the collection.

In fact, this situation is almost certain to occur because of the frequent use of collection classes to represent the many side of one-to-many or many-to-many relationships. Therefore we use the Java Equality concept to define when two objects should really be the same database object.

However, there are other problems with using all the non-id values of an object in the equality test: you really want the test to return true if the objects map to the same row of the the same table in the database (i.e. they represent the same real world concept). But two objects may represent the same real world object and have some different values. For example, two Customer objects may differ in the value of a password property (because the two objects date from different instances in time between which the customer has change her password). But they still refer to the same real world concept: i.e., the same customer.

The solution is to decide on a Business Key for a class. This is like a database key, but involves no generated surrogate keys. Instead it consists of those "real-world" properties of the class that the programmer considers to uniquely identify a particular record. It is not a requirement that the business key absolutely never changes, merely that it changes will not change within the period in which it might be stored in memory in a collection class. For the Customer class on a web application, an appropriate business key might be the customer's email address. This, of course, can change, in which case the customer will be treated as a new different customer. However, this is rarely a significant problem, and if it is, one can always provide a mechanism to reconnect the old data about the customer to the new customer record. More importantly, from our point of view, a change of customer email address is extremely unlikely to affect any reattachment of a detached Customer object to a new session.

Note that Hibernate does not know or care anything about your business keys. As far as it is concerned, reattaching an object works by checking the id property of the object. If it is null, then the object is a new one that could be added to the database but certainly cannot be reattached. Otherwise, the object can be matched up with a record in the database and, on reattachment, the contents of the object are used to update the contents of the corresponding database record(s).

In writing an equals method, there are two important considerations to bear in mind:

Given that, the equals and hashCode methods should be written as follows:

public class Customer
{
    …
    public boolean equals(Object other)
    {
        if (this==other)
            return true;
        if (other==null)
            return false;
        if (!(other instanceof Customer))
            return false;
        final Customer o = (Customer) other;
        return this.emailAddress.equals(o.getEmailAddress());
    }

    public int hashCode()
    {
        return emailAddress.hashCode();
    }
}

A Hibernate object, suitable for mapping into a database, is a normal java bean with a number of extra requirements.

Once you have a Session object, and are executing inside a Transaction, there are a number of ways you can interact with the database.

So far, our discussions above show how to fetch an object from the database if we know its id. Obviously we need more powerful querying facilities.

As described above, one of the simplest ways of querying is simply by invoking a chain of accessor methods on a persistent object:

X x = z.getY().getX()

The most critical type of access that is not covered above is finding an object (or collection of objects) when you have some information about them but not the identifier and you do not have a persistent object available that refers to them. For example, if we want to find the customers whose email address match a given one. Here we can use the session.createQuery method which returns a Query object. The Query object can be executed by invoking list() or iterate() to return, respectively, a list of results or an iterator over the results. The results, i.e. the elements of the list or extracted from the iterator, will either be an object of one of your persistent classes, or a object array containing a list of such objects depending on whether your query asked for one or for a number of objects on each row of the result.

The query language is not SQL but HQL. HQL is very similar to SQL but where, instead of names of tables and columns, the query uses names of java objects and properties. Of course there is a great deal more to it that that and full details can be found in http://www.hibernate.org/5.html:Hibernate On Line Documentation or [BK05]. The following paragraphs gives a little taster of HQL.

The statement

session.createQuery("from customer cust where cust.city=:cityName")
    .setString("cityName", "Birmingham")
    .list() ;

would return a list (java.util.List) of customer objects whose city property was "Birmingham". Naturally, one does not need to chain the method calls but can introduce variables and execute whole operation in separate steps if you wish. Note that instead of the "?" mechanism for JDBC's PreparedStatement, HQL provides a named parameter mechanism which is somewhat more readable and less error-prone. HQL does provide a "?" parameter numbering mechanism, but HQL's numbering starts at 0, whereas JDBC's starts at 1.

In the above query, there was no select clause. The select clause is optional in HQL, but if used, it should contain a list of one or more objects, rather than one or more column names:

Query query = createQuery("select cust, sa " +
                           "from Customer cust, SalesAgent sa " +
                           "where cust.city = sa.city");

This query would find pairs of customers and salesagents in the same city. Thus one might print the results by executing the following:

ArrayList results = query.iterate();
while ( results.hasNext() )
{
    Object[] row = (Object[]) results.next();
    Customer cust = (Customer) row[0];
    SalesAgent sa = (SalesAgent) row[1];
    System.out.format("Customer: %20s, Sales Agent: %20s\n", cust.getName(), sa.getName());
}

Often, a web request may cause a query to be executed which would require a large number of rows to be returned. In such a case, one usually limits the rows to be returned to some limit (say 10 or 20) and allow the user to see them and request for the next block of rows: for example, search engines like Google return only one page of matches at a time. This is called Pagination and Hibernates queries support this in a very simple way. Given a Query object, which should contain a query with a specific ordering, you can use the (chainable) methods setFirstResult() and setMaxResults(), each of which take a single integer argument, to, respectively, choose which row to return first (counting starts at 0) and how many rows to return from there on. The code to return the third page of results (i.e. page 2), where each page holds 10 rows, might thus look like:

int pageSize = 10 ;
int pageNo = 2 ;
Query query = createQuery("select cust, sa " +
                           "from Customer cust, SalesAgent sa " +
                           "where cust.city = sa.city" +
                           "order by cust.name asc, sa.name asc);
query.setFirstResult(pageNo * pageSize);
query.setMaxResults(pageSize);
List customerSalesagentList = query.list();

We have said, a number of times, that when an object is made persistent, that the objects it refers to are also made persistent. This was an oversimplification. In the mapping files for the classes, there is an attribute, cascade, of the various mapping elements (e.g. one-to-one, one-to-many etc.) that lets us control how much, or how little, of a reference graph gets automatically persisted, deleted or updated etc. For a full discussion, see the section on transitive persistence in the Hibernate reference manual. The values that it can be set to, and their meanings when specified on a relationship from a referencing object to one or more referenced objects, are given in the following list. Note that you can have the union of a number of cascade behaviours by writing the behaviours in a comma separated list

It is not normally appropriate to specify any cascade behaviour on a many-to-one or a many-to-many relationship.

In the situation where you have a one-to-one, or a one-to-many relationship, where the referencing object owns the referenced object(s), the appropriate cascade behaviour is all,delete-orphan.

In any other case, if you want some cascade behaviour, but there is no ownership relationship involved (so that, for example if the referencing object is deleted, the objects it refers too can continue to exist in the database) then the appropropiate behaviour is persist,merge,save-update

As we have seen, the standard pattern for executing a use case is to get a Session from the SessionFactory, get a Transaction from the Session, interact with the database via the Session, commit the Transaction and close the Session. Details of the exception handling have been given above. This is fine for normal, fully serialised database transactions but there are two situations when it is not fine:

Hibernate objects, i.e., objects whose persistence Hibernate will manage, can be divided into two types.

The connection between entity beans and database tables and columns is described in a mapping file: usually named X.hbm.xml for class X and stored in the same directory as the compiled file X.class.

The connection between value beans and the database is usually described in the mapping file for the corresponding entity bean.

In the following sections, we will look at the details of how to specify mappings for different types of mappings and classes. We only cover the basic situations. There are many variations possible and great flexibility in all the options and for more complex situations

10.1.  Mapping Simple Entity Classes without Relationships

A basic mapping file is as follows:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="a.b.c">                                    
    <class name="User" table="user" lazy="true">                       
        <id name="id" column="id" type="long">                         
                <generator class="sequence"/>
        </id>
        <version  name="version"     column="version"/>                
        <property name="dateOfBirth" column="dob"    type="date"/>     
        <property name="username"    not-null="true" unique="true"/>   
        <property name="gender"/>                                      
    </class>
</hibernate-mapping>

	The package attribute is optional but using it defines a default package prefix for all classes mentioned in this class mapping specification
	The class element is to specify the class that will be persisted. The name attribute is required. The column attribute is optional (it defaults to a suitable SQL name based on the class name). The lazy attribute is optional (it defaults to false) and specifies that lazy loading of this class via proxies should take place as described previously.
	The id element defines what the primary key of the table should be (again the column attribute is optional). There are a number of options for type and the identifier generator algorithm but leaving it as shown here (i.e., using the database supplied sequence or automatic number generator) is a safe option.
	The use of the optional version element to specify optimistic concurrency control was discussed above. Without this element, no check for lost updates or unrepeatable reads will be made, and, therefore, such problems may occur when reattaching detached objects (irrespective of the transaction isolation level) or when updating the database from a modified persistent object (when the isolation level is read committed or less).
	Types for columns do not need to be specified if they are simple and can be deduced by inspecting the class properties. However, sometimes you want to override the default or specify something a bit more sophisticated.
	We can specify whether a column should be unique (which will create a database constraint) and/or whether it can be null.
	Finally, the simplest case is where we specify nothing but the property name — everything else is taken care of by the defaults.

10.2.  Mapping Value Objects within Entities (Component Mapping)

Sometimes one has properties of entity beans which are more complex than simple base types but which are totally owned by the entity. The standard example is that of an Address object stored as a property of a Person object. In this case there is only one Address object for the Person object.

A Value Component

There are a number of ways this can be handled, but the simplest, which Hibernate calls components is to store both the parent object (Person) and the child (Address) in the same database row, to construct and connect the two objects on reading this row from the database and to coalesce the two objects and write them together when saving or updating either of them. To specify this, you use a component sub-element for the child object in the class element for the parent object instead of the usual property element. Thus, instead of something like

<property name="address" type="string"/>

one would enter:

<component name="address" class="Address">
    <property name="street"   column="user_street"/>
    <property name="postcode" column="user_postcode"/>
</component>

Some details to be aware of are:

1. These child objects are wholly owned by their parents: you cannot have two different parents.

2. A null child property is represented in the database by setting to null all the fields corresponding to the child object. Thus loading such a row will result in a parent object with a null child property, not a parent object with a child object whose properties are all null.

3. Not only can you have multiple components in a class, but one can have multiple components of the same (child) class in a class: simply make sure that the component names are different and that the database field names (the column attributes) are different for the different components.

   Normally, the child object has no way to reference its parent object. However, if you want a property of the child object to refer to its parent, add a element of the form

   <parent name="person"/>

   to make a person property of the child object refer to its parent object.

10.3.  Mapping Entities with Inheritance

Again there are a number of ways Hibernate can handle inheritance. These are based on the standard techniques for reducing generalisation hierarchies in entity-relationship diagrams[BCN91].

The simplest is to use one table for the whole hierarchy. With this design, each row of the table can hold an object of any type from the hierarchy. There is one column for each of the properties in the union of the sets of properties of all the classes in the hierarchy and there is one discriminator column which contains a value (usually of type string, character or integer) used to tell which actual type of object is stored in this particular row. One normally does not make this discriminator a property of the class: it is used only by Hibernate to record and detect the type of the object that a row represents.

An Inheritance Class Hierarchy

<class name="Person" table="people" discriminator-value="P">
    <id name="id" column="id" type="long">
        <generator class="sequence"/>
    </id>
    <version  name="version"         column="version"/>
    <discriminator column="subclass" type="character"/>
    <property name="dateOfBirth"     column="dob" type="date"/>
    <property name="name"/>
    <property name="gender"/>
    <subclass name="Lecturer" discriminator-value="L">
        <property name="office" type="string"/>
        <property name="telephone" type="string"/>
    </subclass>
    <subclass name="Student" discriminator-value="D">
        <property name="studentID" type="integer"/>
    </subclass>
</class>

Here one may not specify any of the subclass fields as not null because the corresponding column will be null in the table for any object of the hierarchy which is not of the subclass that contains the relevant property for that column.

10.4.  Many-to-One, Unidirectional Associations

This corresponds to the standard Java reference to one object from another.

A Many-to-One, Unidirectional Association

In the diagram above, we represent the relationship between students and their thesis supervisors. In this design, a student can have no more than one supervisor but may not (yet) have any. However, a lecturer may have any number, including zero, of students to supervise. Furthermore, we only allow a one directional link: Student has a property (say getSupervisor/setSupervisor) but there is no direct way, starting with a Lecturer object, to find the students that the lecturer supervises.

If we start with the simple, non-related, base entity mapping files for Student and Lecturer, we add this association by adding the following, as a sub-element of the class element, to the mapping file for Student:

<many-to-one name="supervisor"	column="supervisor"/>

This element acts very much like a normal property element in that it defines the mapping between the supervisor property of Student and the column in the students table. However, it also sets up the relationship so that, after getting a Student object from the database, if we use the supervisor accessor of that Student object, we will get the corresponding Lecturer object (or a proxy thereof if we have enabled lazy loading of the Lecturer objects). Finally, it ensures that the underlying database is created with a foreign key constraint that the supervisor column is a foreign key into the lecturers table.

As things stand, there is now a question of what you want the cascade behaviour of the relationship to be (see the section on cascade above). Without adding the optional cascade attribute to the many-to-one element, then the Lecturer object on the other end of the association is ignored when the Student object is saved, updated, deleted or when its supervisor property is reset away from it. Certainly we would not want the lecturer to be removed from the database when the student is deleted or when the student no longer has that lecturer as his or her supervisor; so none of the delete or all options are appropriate. But what about save-update?. There are two scenarios under which this might have an effect:

1. If you create a new (transient) lecturer and make a persistent student refer to it. In fact, for this particular object design, one would never do such a thing: the obvious semantics of the situation dictate that you cannot just invent new lecturers on demand: you would always have to have the lecturer as a currently existing object in the database before setting the student's supervisor property to that lecturer. Since the scenario will never arise, this is neither a vote for or against using the save-update option.

2. If the Student, and associated Lecturer objects were detached, and now you reattach the Student object, then you need the save-update option if you want the Lecturer object to be reattached automatically. Without that, you need to reattach it directly yourself — an easy task to overlook and therefore a source of bugs. This therefore, is a vote for set the cascade="save-update" option.

Note that you can specify unique="true" as an attribute of the many-to-one element. This has the effect of disallowing the possibility of having two student rows with the same supervisor values, i.e., turning the "*" on the Student side of the class diagram into a "0..1" or limiting each lecturer to having at most one supervisee. Similarly, specifying not-null="true" adds the requirement that every student must have a valid supervisor, i.e., it changes the "0..1" on the Lecturer side of the diagram to a "1".

10.5.  One-to-Many, Unidirectional Associations

This relationship is essentially the same as last one, but now we choose the opposite direction for navigating the connection. Thus our Lecturer object now has a property which is a collection of Student objects while the Student objects have no properties which refer to their supervising Lecturer.

	Warning
	For reasons described below, we would (almost) never use such an association: it is inefficient and there is almost no overhead in converting it to a much more efficient bidirectional association. Nonetheless, it is useful to discuss this case as a first step towards the bidirectional version of the association.

A One-to-Many, Unidirectional Association

As far as the database is concerned, there is no difference between this and the unidirectional many-to-one association: there will still be a single column in the table holding the Student objects that contains a foreign key into the table holding the Lecturer objects.

Now that entities are being stored in collections, it becomes critical that you have appropriately implemented equals and hashCode methods for those entities. In particular, you should ensure that these methods are independent of the generated surrogate keys and that trivial changes to the object do not effect the methods while the objects are in the collections.

The simplest collection, for our purposes, is a Set. To create the association, we add a Set valued property to Lecturer

<set name="advisees" cascade="save-update" lazy="true">
    <key column="lecturer_id"/>
    <one-to-many class="Student"/>
</set>

Here, we define a property of Lecturer which is Set valued. The name of the property is advisees. This property is to capture a one-to-many association to the Student class and it this association is to be implemented in the database as a foreign key to the table holding Lecturer objects stored in the column lecturer_id in the table holding Student objects.

There are a number of constraints imposed by the use of this one-to-many association which arises from the fact that it is represented by this "reverse" link from the contained object side of the association:

1. From a Java point of view, we could potentially have two different Lecturer objects, both of which have the same Student object in their container. However, this is not possible for a one-to-many association because, in the database, each Student row refers to the single Lecturer row which contains it. If you want the true Java semantics, you have to represent the association as a many-to-many one.

2. You cannot have the same object multiple times in the same collection. This is obvious when the collection property is of type Set, but one could use other types, such as List. However, the implementation of association by the reverse foreign key makes this impossible. Again, a many-to-many association can provide the appropriate semantics

Finally, there is the question of why one-to-many associations between entities cause problems. Consider the following code:

tx = session.beginTransaction();
Lecturer lect = new Lecturer("Gordon Brown") ;
lect.getAdvisees().add(new Student("Tony Blair")) ;
lect.getAdvisees().add(new Student("Michael Howard")) ;
session.save(lect);
tx.commit();

Note that the association belongs to the Lecturer class (as it is defined in Lecturer's mapping file). This means that adding a student to a lecturer's advisees is considered an operation on a lecturer, not on a student. Thus the SQL statements that would be generated for the above statements would include an insert for the lecturer object, together with an insert each for the two connected student objects (because the students are referred to by the lecturer and we have put the cascade="save-update" declaration in the Lecturer's mapping file). But because the association does not belong to the students, the saving of the students would not set the foreign key value to the advising lecture. Thus there would be two extra update statements for adding the lecturer's foreign key value into the student records. These extra two update statements are not just an efficiency problem: If every student should have a supervisor, then we would like to add the not-null="true" attribute to the key element in the mapping file for the association. However this would cause errors as the above sequence of inserts and updates does insert nulls (if only to immediately update them) where they should never occur.

The solution is to only create such one-to-many associations as the inverse end of a bidirectional many-to-one association. This gives ownership of the association to the Student end and, as we see below, leads to the foreign key being created as part of the initial insert of the Student record instead of after it as a consequence of the Lecturer insert.

10.6.  Many-to-one, bidirectional Associations

In this case we allow navigation in both directions between the two classes. On the Many side it is a standard java reference. on the One side it is a collection. However, the two associations are not independent of each other but rather, one is the inverse of the other and the same foreign key column is used for both associations. Thus our Lecturer object now has a property which is a collection of Student objects while the Student objects have a properties which refers to the Student's supervising Lecturer.

A Many-to-One, bidirectional Association

To achieve this, we start by using the many-to-one element as before in the mapping file for the Student class, and the Set element as before in the mapping file for the Lecturer class, ensuring that both associations use the same column in Student's table to encode the association. Then we add a new attribute, inverse="true" to the set element in Lecturer's mapping file. Without this, adding a new Student as an advisee to a Lecturer would trigger Hibernate to set the foreign key column of the Student table twice: once for each association that has been changed. The inverse attribute tells hibernate that Student owns the association and that Hibernate should not trigger updates of the foreign key column when it changes on the Lecturer side.

Thus the mapping file for Lecturer looks like this:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
          "-//Hibernate/Hibernate Mapping DTD//EN"
          "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
    <class name="Lecturer" table="lecturers">
        <id name="id" column="lecturer_id">
            <generator class="sequence"/>
        </id>
        <version name="version" column="version"/>
        <property name="name" column="name"/>
        <set name="advisees" inverse="true" cascade="save-update" lazy="true">
            <key column="lecturer_id"/>
            <one-to-many class="Student"/>
        </set>
    </class>
</hibernate-mapping>

The mapping file for student is as follows:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
          "-//Hibernate/Hibernate Mapping DTD//EN"
          "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
    <class name="Student" table="students">
        <id name="id" column="student_id">
            <generator class="sequence"/>
        </id>
        <version name="version" column="version"/> 
        <property name="name" column="name"/>
        <property name="regNo" column="reg_no"/>
        <many-to-one name="advisor" column="lecturer_id" cascade="save-update"/>
    </class>
</hibernate-mapping>

Now all the programmer has to do is to ensure that, when the Lecturer's advisee property property is changed, the corresponding correct changes are made to the appropriate Student's advisor property. So long as both are done together, the Java object graph will be correct and the correct update on disk will be made as well. Furthermore, since the association belongs to the Student, there will never be an insert of a Student record with a null Lecturer foreign key if the Student has an advisor, thus avoiding not-null constraint breaking. To ensure that these updates are made together, it is usual to add some convenience methods: in Lecturer, change the getAdvisees() and setAdvisees() methods to private and add a convenience method to update the object graph correctly when adding a new Student advisee to a Lecturer:

    public void addAdvisee(Student st)
    {
        Lecturer oldAdvisor = st.getAdvisor() ;
        if (oldAdvisor != this)
        {
            if (oldAdvisor != null)
                oldAdvisor.getAdvisees().remove(st) ;
            st.setAdvisor(this);
            advisees.add(st) ;
        }
    }

Note how we are careful to correctly handle removal of a Student from a previous advising Lecturer before adding it to this one. Whether you need to do something similar for your code will depend on your detailed design.

If we have a true composition relationship, i.e., a parent-child relationship where if the parent gets deleted then the child should also be deleted etc., then we should change the cascade attribute on the set element in the Lecturer mapping file to be all-delete-orphan.

There is still plenty more to learn about Hibernate. There are one-to-one and many-to-many associations, value (as opposed to entity) collections, outer-join and batch fetching, Iterate queries, Criteria queries and the whole of the HQL query language, not to mention explicit SQL queries. There are alternative strategies for inheritance hierarchy mapping and polymorphism handling. There are user-defined data types and mappings, Interceptors, caching and all the Hibernate related tools. All of this and more are discussed on the Hibernate web site and in the book.