Class in Basic O/R Mapping of Hibernate by R4R Team

As we given in below example with that type we can declare persistence class using the class element. Example:

        where="arbitrary sql where condition"         
        check="arbitrary sql check condition"         
        subselect="SQL expression"                    



Name (optional)

We use here java class nae of the persistent class or interfaces. When we miss this attribute then it assumed that the mapping is for a non-POJO entity.


It is defaults to the class name.

And it is the database table name also.


It defaults to the class name.

Here a value that distinguises individual subclasses that is used for polymorphic behavior. Here acceptable values include null and not null.


It is defaults true.

It specifies that instances of the class are not mutable.


It overides the schema name specified by the root <hibernate-mapping> element.


It overrides the schema name specified by the root <hibernate-mapping> element.


It specifies an interfaces to use for lazy initilizing proxies. Than we can specifies the name of the class itself.


It is defaults on the false.

It specifies that UPDATE SQL should be generated at runtime and can contain only those columns whose values have changed.


It is defaults false.

It specifies that the INSERT SQL should be generated at runtime and contain only the column whose values are not null.


It is defaults false.

It specifies that hibernate should never perform an SQL UPDATE UNLESS it is certain that an object is actually modified. Only when a transient objectttt has been associated with a new session using update(), that will hibernate perform an extra SQL SELECT TO determine if an UPDATE is actually required.


It defaults to implicit.

It determine whether implicit or explicit query in the polymorphism is used.


It specifies an arbitary SQLWHERE condition to be used when retrieving objects of this class.


It specifies a custom ClassPersister.


It defaults on 1.

it specifiest a “batch-size” for fetching instances of this class by identifier.


It defaults to version.

It determines the optimistic locking strategy.


It defaults name is class name.

Hibernate3 allows a class to be mapped multiple times, potentially to different tables. It also allows entity mappings that are represented by Maps or XML at the Java level. In these cases, you should provide an explicit arbitrary name for the entity. See Section 4.4, “Dynamic models” and Chapter 18, XML Mapping for more information.

check (optional)

SQL expression used to generate a multi-row check constraint for automatic schema generation.

rowid (optional)

ibernate can use ROWIDs on databases. On Oracle, for example, Hibernate can use the rowid extra column for fast updates once this option has been set to rowid. A ROWID is an implementation detail and represents the physical location of a stored tuple.

subselect (optional)

maps an immutable and read-only entity to a database subselect. This is useful if you want to have a view instead of a base table. See below for more information.

abstract (optional)

it is used to mark abstract superclasses in <union-subclass> hierarchies

It is acceptable for the named persistent class to be an interface. You can declare implementing classes of that interface using the <subclass> element. You can persist any static inner class. Specify the class name using the standard form i.e. e.g.Foo$Bar.

Immutable classes, mutable="false", cannot be updated or deleted by the application. This allows Hibernate to make some minor performance optimizations.

The optional proxy attribute enables lazy initialization of persistent instances of the class. Hibernate will initially return CGLIB proxies that implement the named interface. The persistent object will load when a method of the proxy is invoked. See "Initializing collections and proxies" below.

Implicit polymorphism means that instances of the class will be returned by a query that names any superclass or implemented interface or class, and that instances of any subclass of the class will be returned by a query that names the class itself. Explicit polymorphism means that class instances will be returned only by queries that explicitly name that class. Queries that name the class will return only instances of subclasses mapped inside this <class> declaration as a <subclass> or <joined-subclass>. For most purposes, the default polymorphism="implicit" is appropriate. Explicit polymorphism is useful when two different classes are mapped to the same table This allows a "lightweight" class that contains a subset of the table columns.

The persister attribute lets you customize the persistence strategy used for the class. You can, for example, specify your own subclass of org.hibernate.persister.EntityPersister, or you can even provide a completely new implementation of the interface org.hibernate.persister.ClassPersister that implements, for example, persistence via stored procedure calls, serialization to flat files or LDAP. See org.hibernate.test.CustomPersister for a simple example of "persistence" to a Hashtable.

The dynamic-update and dynamic-insert settings are not inherited by subclasses, so they can also be specified on the <subclass> or <joined-subclass> elements. Although these settings can increase performance in some cases, they can actually decrease performance in others.

Use of select-before-update will usually decrease performance. It is useful to prevent a database update trigger being called unnecessarily if you reattach a graph of detached instances to a Session.

If you enable dynamic-update, you will have a choice of optimistic locking strategies:

version: check the version/timestamp columns
all: check all columns
dirty: check the changed columns, allowing some concurrent updates
none: do not use optimistic locking
It is strongly recommended that you use version/timestamp columns for optimistic locking with Hibernate. This strategy optimizes performance and correctly handles modifications made to detached instances (i.e. when Session.merge() is used).

There is no difference between a view and a base table for a Hibernate mapping. This is transparent at the database level, although some DBMS do not support views properly, especially with updates. Sometimes you want to use a view, but you cannot create one in the database (i.e. with a legacy schema). In this case, you can map an immutable and read-only entity to a given SQL subselect expression:

<class name="Survay">
        select, max(bid.amount), count(*)
        from item
        join bid on bid.item_id =
        group by
    <synchronize table="item"/>
    <synchronize table="bid"/>
    <id name="name"/>

Declare the tables to synchronize this entity with, ensuring that auto-flush happens correctly and that queries against the derived entity do not return stale data. The <subselect> is available both as an attribute and a nested mapping element.
Leave a Comment:
R4R Team
R4Rin Top Tutorials are Core Java,Hibernate ,Spring,Sturts.The content on website is done by expert team not only with the help of books but along with the strong professional knowledge in all context like coding,designing, marketing,etc!