Hibernate defines and supports the following object states:

We will now discuss the states and state transitions (and the Hibernate methods that trigger a transition) in more detail.

Newly instantiated instances of a persistent class are considered transient by Hibernate. We can make a transient instance persistent by associating it with a session:

DomesticCat fritz = new DomesticCat();

fritz.setColor(Color.GINGER);

fritz.setSex('M');

fritz.setName("Fritz");

Long generatedId = (Long) sess.save(fritz);

If Cat has a generated identifier, the identifier is generated and assigned to the cat when save() is called. If Cat has an assigned identifier, or a composite key, the identifier should be assigned to the cat instance before calling save(). You can also use persist() instead of save(), with the semantics defined in the EJB3 early draft.

Alternatively, you can assign the identifier using an overloaded version of save().

DomesticCat pk = new DomesticCat();

pk.setColor(Color.TABBY);

pk.setSex('F');

pk.setName("PK");

pk.setKittens( new HashSet() );

pk.addKitten(fritz);

sess.save( pk, new Long(1234) );

If the object you make persistent has associated objects (e.g. the kittens collection in the previous example), these objects can be made persistent in any order you like unless you have a NOT NULL constraint upon a foreign key column. There is never a risk of violating foreign key constraints. However, you might violate a NOT NULL constraint if you save() the objects in the wrong order.

Usually you do not bother with this detail, as you will normally use Hibernate's transitive persistence feature to save the associated objects automatically. Then, even NOT NULL constraint violations do not occur - Hibernate will take care of everything. Transitive persistence is discussed later in this chapter.

The load() methods of Session provide a way of retrieving a persistent instance if you know its identifier. load() takes a class object and loads the state into a newly instantiated instance of that class in a persistent state.

Cat fritz = (Cat) sess.load(Cat.class, generatedId);

// you need to wrap primitive identifiers

long id = 1234;

DomesticCat pk = (DomesticCat) sess.load( DomesticCat.class, new Long(id) );

Alternatively, you can load state into a given instance:

Cat cat = new DomesticCat();

// load pk's state into cat

sess.load( cat, new Long(pkId) );

Set kittens = cat.getKittens();

Be aware that load() will throw an unrecoverable exception if there is no matching database row. If the class is mapped with a proxy, load() just returns an uninitialized proxy and does not actually hit the database until you invoke a method of the proxy. This is useful if you wish to create an association to an object without actually loading it from the database. It also allows multiple instances to be loaded as a batch if batch-size is defined for the class mapping.

If you are not certain that a matching row exists, you should use the get() method which hits the database immediately and returns null if there is no matching row.

Cat cat = (Cat) sess.get(Cat.class, id);

if (cat==null) {

    cat = new Cat();

    sess.save(cat, id);

}

return cat;

You can even load an object using an SQL SELECT ... FOR UPDATE, using a LockMode. See the API documentation for more information.

Cat cat = (Cat) sess.get(Cat.class, id, LockMode.UPGRADE);

Any associated instances or contained collections will not be selected FOR UPDATE, unless you decide to specify lock or all as a cascade style for the association.

It is possible to re-load an object and all its collections at any time, using the refresh() method. This is useful when database triggers are used to initialize some of the properties of the object.

sess.save(cat);

sess.flush(); //force the SQL INSERT

sess.refresh(cat); //re-read the state (after the trigger executes)

How much does Hibernate load from the database and how many SQL SELECTs will it use? This depends on the fetching strategy. This is explained in Section 20.1, “Fetching strategies”.

If you do not know the identifiers of the objects you are looking for, you need a query. Hibernate supports an easy-to-use but powerful object oriented query language (HQL). For programmatic query creation, Hibernate supports a sophisticated Criteria and Example query feature (QBC and QBE). You can also express your query in the native SQL of your database, with optional support from Hibernate for result set conversion into objects.

List cats = session.createQuery(

    "from Cat as cat where cat.birthdate < ?")

    .setDate(0, date)

    .list();


List mothers = session.createQuery(

    "select mother from Cat as cat join cat.mother as mother where cat.name = ?")

    .setString(0, name)

    .list();


List kittens = session.createQuery(

    "from Cat as cat where cat.mother = ?")

    .setEntity(0, pk)

    .list();


Cat mother = (Cat) session.createQuery(

    "select cat.mother from Cat as cat where cat = ?")

    .setEntity(0, izi)

    .uniqueResult();]]


Query mothersWithKittens = (Cat) session.createQuery(

    "select mother from Cat as mother left join fetch mother.kittens");

Set uniqueMothers = new HashSet(mothersWithKittens.list());

// fetch ids

Iterator iter = sess.createQuery("from eg.Qux q order by q.likeliness").iterate();

while ( iter.hasNext() ) {

    Qux qux = (Qux) iter.next();  // fetch the object

    // something we couldnt express in the query

    if ( qux.calculateComplicatedAlgorithm() ) {

        // delete the current instance

        iter.remove();

        // dont need to process the rest

        break;

    }

}

Iterator kittensAndMothers = sess.createQuery(

            "select kitten, mother from Cat kitten join kitten.mother mother")

            .list()

            .iterator();


while ( kittensAndMothers.hasNext() ) {

    Object[] tuple = (Object[]) kittensAndMothers.next();

    Cat kitten = (Cat) tuple[0];

    Cat mother = (Cat) tuple[1];

    ....

}

Iterator results = sess.createQuery(

        "select cat.color, min(cat.birthdate), count(cat) from Cat cat " +

        "group by cat.color")

        .list()

        .iterator();


while ( results.hasNext() ) {

    Object[] row = (Object[]) results.next();

    Color type = (Color) row[0];

    Date oldest = (Date) row[1];

    Integer count = (Integer) row[2];

    .....

}

//named parameter (preferred)

Query q = sess.createQuery("from DomesticCat cat where cat.name = :name");

q.setString("name", "Fritz");

Iterator cats = q.iterate();

//positional parameter

Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");

q.setString(0, "Izi");

Iterator cats = q.iterate();

//named parameter list

List names = new ArrayList();

names.add("Izi");

names.add("Fritz");

Query q = sess.createQuery("from DomesticCat cat where cat.name in (:namesList)");

q.setParameterList("namesList", names);

List cats = q.list();

Query q = sess.createQuery("from DomesticCat cat");

q.setFirstResult(20);

q.setMaxResults(10);

List cats = q.list();

Query q = sess.createQuery("select cat.name, cat from DomesticCat cat " +

                            "order by cat.name");

ScrollableResults cats = q.scroll();

if ( cats.first() ) {


    // find the first name on each page of an alphabetical list of cats by name

    firstNamesOfPages = new ArrayList();

    do {

        String name = cats.getString(0);

        firstNamesOfPages.add(name);

    }

    while ( cats.scroll(PAGE_SIZE) );


    // Now get the first page of cats

    pageOfCats = new ArrayList();

    cats.beforeFirst();

    int i=0;

    while( ( PAGE_SIZE > i++ ) && cats.next() ) pageOfCats.add( cats.get(1) );


}

cats.close()

<query name="ByNameAndMaximumWeight"><![CDATA[

    from eg.DomesticCat as cat

        where cat.name = ?

        and cat.weight > ?

] ]></query>

Query q = sess.getNamedQuery("ByNameAndMaximumWeight");

q.setString(0, name);

q.setInt(1, minWeight);

List cats = q.list();

Collection blackKittens = session.createFilter(

    pk.getKittens(), 

    "where this.color = ?")

    .setParameter( Color.BLACK, Hibernate.custom(ColorUserType.class) )

    .list()

);

Collection blackKittenMates = session.createFilter(

    pk.getKittens(), 

    "select this.mate where this.color = eg.Color.BLACK.intValue")

    .list();

Collection tenKittens = session.createFilter(

    mother.getKittens(), "")

    .setFirstResult(0).setMaxResults(10)

    .list();

Criteria crit = session.createCriteria(Cat.class);

crit.add( Restrictions.eq( "color", eg.Color.BLACK ) );

crit.setMaxResults(10);

List cats = crit.list();

List cats = session.createSQLQuery("SELECT {cat.*} FROM CAT {cat} WHERE ROWNUM<10")

    .addEntity("cat", Cat.class)

.list();

List cats = session.createSQLQuery(

    "SELECT {cat}.ID AS {cat.id}, {cat}.SEX AS {cat.sex}, " +

           "{cat}.MATE AS {cat.mate}, {cat}.SUBCLASS AS {cat.class}, ... " +

    "FROM CAT {cat} WHERE ROWNUM<10")

    .addEntity("cat", Cat.class)

.list()

Transactional persistent instances (i.e. objects loaded, saved, created or queried by the Session) can be manipulated by the application, and any changes to persistent state will be persisted when the Session is flushed. This is discussed later in this chapter. There is no need to call a particular method (like update(), which has a different purpose) to make your modifications persistent. The most straightforward way to update the state of an object is to load() it and then manipulate it directly while the Session is open:

DomesticCat cat = (DomesticCat) sess.load( Cat.class, new Long(69) );

cat.setName("PK");

sess.flush();  // changes to cat are automatically detected and persisted

Sometimes this programming model is inefficient, as it requires in the same session both an SQL SELECT to load an object and an SQL UPDATE to persist its updated state. Hibernate offers an alternate approach by using detached instances.

Many applications need to retrieve an object in one transaction, send it to the UI layer for manipulation, then save the changes in a new transaction. Applications that use this kind of approach in a high-concurrency environment usually use versioned data to ensure isolation for the "long" unit of work.

Hibernate supports this model by providing for reattachment of detached instances using the Session.update() or Session.merge() methods:

// in the first session

Cat cat = (Cat) firstSession.load(Cat.class, catId);

Cat potentialMate = new Cat();

firstSession.save(potentialMate);


// in a higher layer of the application

cat.setMate(potentialMate);


// later, in a new session

secondSession.update(cat);  // update cat

secondSession.update(mate); // update mate

If the Cat with identifier catId had already been loaded by secondSession when the application tried to reattach it, an exception would have been thrown.

Use update() if you are certain that the session does not contain an already persistent instance with the same identifier. Use merge() if you want to merge your modifications at any time without consideration of the state of the session. In other words, update() is usually the first method you would call in a fresh session, ensuring that the reattachment of your detached instances is the first operation that is executed.

The application should individually update() detached instances that are reachable from the given detached instance only if it wants their state to be updated. This can be automated using transitive persistence. See Section 10.11, “Transitive persistence” for more information.

The lock() method also allows an application to reassociate an object with a new session. However, the detached instance has to be unmodified.

//just reassociate:

sess.lock(fritz, LockMode.NONE);

//do a version check, then reassociate:

sess.lock(izi, LockMode.READ);

//do a version check, using SELECT ... FOR UPDATE, then reassociate:

sess.lock(pk, LockMode.UPGRADE);

Note that lock() can be used with various LockModes. See the API documentation and the chapter on transaction handling for more information. Reattachment is not the only usecase for lock().

Other models for long units of work are discussed in Section 12.3, “Optimistic concurrency control”.

Hibernate users have requested a general purpose method that either saves a transient instance by generating a new identifier or updates/reattaches the detached instances associated with its current identifier. The saveOrUpdate() method implements this functionality.

// in the first session

Cat cat = (Cat) firstSession.load(Cat.class, catID);


// in a higher tier of the application

Cat mate = new Cat();

cat.setMate(mate);


// later, in a new session

secondSession.saveOrUpdate(cat);   // update existing state (cat has a non-null id)

secondSession.saveOrUpdate(mate);  // save the new instance (mate has a null id)

The usage and semantics of saveOrUpdate() seems to be confusing for new users. Firstly, so long as you are not trying to use instances from one session in another new session, you should not need to use update(), saveOrUpdate(), or merge(). Some whole applications will never use either of these methods.

Usually update() or saveOrUpdate() are used in the following scenario:

saveOrUpdate() does the following:

and merge() is very different:

Session.delete() will remove an object's state from the database. Your application, however, can still hold a reference to a deleted object. It is best to think of delete() as making a persistent instance, transient.

sess.delete(cat);

You can delete objects in any order, without risk of foreign key constraint violations. It is still possible to violate a NOT NULL constraint on a foreign key column by deleting objects in the wrong order, e.g. if you delete the parent, but forget to delete the children.

It is sometimes useful to be able to take a graph of persistent instances and make them persistent in a different datastore, without regenerating identifier values.

//retrieve a cat from one database

Session session1 = factory1.openSession();

Transaction tx1 = session1.beginTransaction();

Cat cat = session1.get(Cat.class, catId);

tx1.commit();

session1.close();


//reconcile with a second database

Session session2 = factory2.openSession();

Transaction tx2 = session2.beginTransaction();

session2.replicate(cat, ReplicationMode.LATEST_VERSION);

tx2.commit();

session2.close();

The ReplicationMode determines how replicate() will deal with conflicts with existing rows in the database:

Usecases for this feature include reconciling data entered into different database instances, upgrading system configuration information during product upgrades, rolling back changes made during non-ACID transactions and more.

Sometimes the Session will execute the SQL statements needed to synchronize the JDBC connection's state with the state of objects held in memory. This process, called flush, occurs by default at the following points:

The SQL statements are issued in the following order:

An exception is that objects using native ID generation are inserted when they are saved.

Except when you explicitly flush(), there are absolutely no guarantees about when the Session executes the JDBC calls, only the order in which they are executed. However, Hibernate does guarantee that the Query.list(..) will never return stale or incorrect data.

It is possible to change the default behavior so that flush occurs less frequently. The FlushMode class defines three different modes: only flush at commit time when the Hibernate Transaction API is used, flush automatically using the explained routine, or never flush unless flush() is called explicitly. The last mode is useful for long running units of work, where a Session is kept open and disconnected for a long time (see Section 12.3.2, “Extended session and automatic versioning”).

sess = sf.openSession();

Transaction tx = sess.beginTransaction();

sess.setFlushMode(FlushMode.COMMIT); // allow queries to return stale state


Cat izi = (Cat) sess.load(Cat.class, id);

izi.setName(iznizi);


// might return stale data

sess.find("from Cat as cat left outer join cat.kittens kitten");


// change to izi is not flushed!

...

tx.commit(); // flush occurs

sess.close();

During flush, an exception might occur (e.g. if a DML operation violates a constraint). Since handling exceptions involves some understanding of Hibernate's transactional behavior, we discuss it in Chapter 12, Transactions and Concurrency.

It is quite cumbersome to save, delete, or reattach individual objects, especially if you deal with a graph of associated objects. A common case is a parent/child relationship. Consider the following example:

If the children in a parent/child relationship would be value typed (e.g. a collection of addresses or strings), their life cycle would depend on the parent and no further action would be required for convenient "cascading" of state changes. When the parent is saved, the value-typed child objects are saved and when the parent is deleted, the children will be deleted, etc. This works for operations such as the removal of a child from the collection. Since value-typed objects cannot have shared references, Hibernate will detect this and delete the child from the database.

Now consider the same scenario with parent and child objects being entities, not value-types (e.g. categories and items, or parent and child cats). Entities have their own life cycle and support shared references. Removing an entity from the collection does not mean it can be deleted), and there is by default no cascading of state from one entity to any other associated entities. Hibernate does not implement persistence by reachability by default.

For each basic operation of the Hibernate session - including persist(), merge(), saveOrUpdate(), delete(), lock(), refresh(), evict(), replicate() - there is a corresponding cascade style. Respectively, the cascade styles are named create, merge, save-update, delete, lock, refresh, evict, replicate. If you want an operation to be cascaded along an association, you must indicate that in the mapping document. For example:

<one-to-one name="person" cascade="persist"/>

Cascade styles my be combined:

<one-to-one name="person" cascade="persist,delete,lock"/>

You can even use cascade="all" to specify that all operations should be cascaded along the association. The default cascade="none" specifies that no operations are to be cascaded.

A special cascade style, delete-orphan, applies only to one-to-many associations, and indicates that the delete() operation should be applied to any child object that is removed from the association.

Recommendations:

Mapping an association (either a single valued association, or a collection) with cascade="all" marks the association as a parent/child style relationship where save/update/delete of the parent results in save/update/delete of the child or children.

Furthermore, a mere reference to a child from a persistent parent will result in save/update of the child. This metaphor is incomplete, however. A child which becomes unreferenced by its parent is not automatically deleted, except in the case of a <one-to-many> association mapped with cascade="delete-orphan". The precise semantics of cascading operations for a parent/child relationship are as follows:

Finally, note that cascading of operations can be applied to an object graph at call time or at flush time. All operations, if enabled, are cascaded to associated entities reachable when the operation is executed. However, save-update and delete-orphan are transitive for all associated entities reachable during flush of the Session.

Hibernate requires a rich meta-level model of all entity and value types. This model can be useful to the application itself. For example, the application might use Hibernate's metadata to implement a "smart" deep-copy algorithm that understands which objects should be copied (eg. mutable value types) and which objects that should not (e.g. immutable value types and, possibly, associated entities).

Hibernate exposes metadata via the ClassMetadata and CollectionMetadata interfaces and the Type hierarchy. Instances of the metadata interfaces can be obtained from the SessionFactory.

Cat fritz = ......;

ClassMetadata catMeta = sessionfactory.getClassMetadata(Cat.class);


Object[] propertyValues = catMeta.getPropertyValues(fritz);

String[] propertyNames = catMeta.getPropertyNames();

Type[] propertyTypes = catMeta.getPropertyTypes();


// get a Map of all properties which are not collections or associations

Map namedValues = new HashMap();

for ( int i=0; i<propertyNames.length; i++ ) {

    if ( !propertyTypes[i].isEntityType() && !propertyTypes[i].isCollectionType() ) {

        namedValues.put( propertyNames[i], propertyValues[i] );

    }

}