Hibernate3 Tip#7: find(), merge(), getReference()

find() is for retrieving objects from the database - always generates SQL and loads into memory an object initialized according to the active fetch strategy. If you have newly created objects in a persistent context but have not called flush() or committed the transaction, find() will not find them and will return NULL (even if you have called persist()).

merge() is for retrieving a persistent version of a detached or transient object. If not found in the persistent context caches, an SQL statement is issued to retrieve the object from the database, and dirty checking is done to merge the objects. Because it uses non-NULL properties of the detached or transient object to overwrite the retrieved object, you want to be careful about how you use attribute defaults. So watch out when working with transient objects.

getReference() returns a proxy with only the identifier initialized, and does not hit the database. If you are not working directly on an object (such as when it is used only as a reference in queries or other objects), you want to use this strategy. Rule of thumb: if you have entity references in an object, this is likely how you refer to them. Note that the proxy has all other properties set to NULL. To fully initialize the proxies, you'd need to find() or merge().

Hibernate3 Tip#6: QL Parameters Are Objects

Consider an entity User that has a many-to-one reference to a Role entity. Each of these entities has an identifier field used to uniquely identify objects. The database schema would be such that the Users table has a column (usually of a numeric data type) with a foreign key constraint to a Role. Supposing you wanted to get all users with a specific role, plain SQL allows querying with a "where user.roleid=?" and providing a numeric type that matches the role's identifier type.

In Hibernate, however, this strategy fails with a "org.hibernate.PropertyAccessViolation: could not get a field value by reflection" exception. Hibernate expects you to provide actual objects as parameters. Thus the QL for the above scenario would require you to find the persistent Role object first, then pass it (or its proxy given by getReference()) as a parameter. Alternatively, you may choose to use native SQL queries. You may consider this a side effect of using an object-oriented persistent layer and query language. It is particularly useful in resolving object identity issues where perhaps more than one property is used to define the object's primary key.

Hibernate3 Tip#5: Initializing Entity Objects

When you create entity classes, it is NOT a good idea to initialize entity references with defaults. Only initialize class attributes that are not references to other entities, and leave references NULLed, except the collections. A new identifier is assigned when a transient object is persisted, overriding whatever default you might have assigned. Having defaults may cause dirty checking to consider them changes that should be propagated to the database when merging or reattaching objects. For newly created objects, the dynamic update feature (if enabled) prevents sql statements that consist of null values (see this tip), and the database uses whatever the default is. (It is better for defaults to be defined in the @Column annotation).

When modifying objects, you only need change what needs to be changed, and if you have dirty checking enabled, only those changes will be propagated to the database. Also note that if you want to use a specific identifier for an object, you should call merge() to obtain a persistent version with that identifier almost immediately after initializing it. Otherwise you'll get a "detached object passed to persist ..." exception sometime when you attempt to commit the transaction. This is one pesky annoyance you discover only with experience.

Hibernate3 Tip#4: One EntityManagerFactory Per Persistence Unit

If you use Hibernate3 for web applications, you must define a persistence unit (database connection and entity metadata from annotated classes or XML mappings). These are essentially the settings that describe how to connect to the database and describe the schema i.e. how tables are laid out and various relationships/constraints between the tables physically.

At runtime, you make persistence unit configuration available to the web application through an entity manager factory. Its main job is to instantiate entity managers for you that provide the persistence context in which you manipulate the database. Although you can create multiple factories based on a single persistence unit, it is not recommended. Instead, you ought to instantiate one statically-scoped entity manager factory and provide a thread-safe accessor that employs the singleton pattern to ensure there's always only one. That accessor initializes a new EMF if none exists and return EntityManager objects.

An example that uses a persistence unit called "puGeldzin":

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

public final class DBUtil {
private static EntityManagerFactory emf;

public static synchronized EntityManager entityManager() {
    if(emf == null) {
        emf = Persistence
            .createEntityManagerFactory("puGeldzin");
    }
    return emf.createEntityManager();
}
}