What types of classes can Hibernate persist?

Question

I want to know whether hibernate imposes any restrictions for specific types of classes to persist them. I have read that Hibernate can persist JavaBean classes and Pojos.

Does it mean that hibernate cannot persist classes which does not fall into those two categories?

Can we persist non-pojo classes in hibernate? e.g

Class A extends B{}

Basically I need to know what makes hibernate unable to persist a class in a RDBMS?

Answer 1

From practice I know about such limitations of object persisting:

1. Only class marked with @Entity can be persisted, but not all super classes must have this annotation.
2. You can not use interfaces or non entity classes for field type in entity (for persisting purpose).
3. And that's why you can not use full power of generics in entities.

In real world pojo and java beans is not all what you need and want for successful work.

Answer 2

Persistent classes are classes in an application that implement the entities of the business problem (e.g. Customer and Order in an E-commerce application). Not all instances of a persistent class are considered to be in the persistent state. For example, an instance can instead be transient or detached.

Hibernate works best if these classes follow some simple rules, also known as the Plain Old Java Object (POJO) programming model. However, none of these rules are hard requirements. Indeed, Hibernate3 assumes very little about the nature of your persistent objects. You can express a domain model in other ways (using trees of Map instances, for example).

Most Java applications require a persistent class representing felines. For example:

public class Cat {
private Long id; // identifier

private Date birthdate;
private Color color;
private char sex;
private float weight;
private int litterId;

private Cat mother;
private Set kittens = new HashSet();

private void setId(Long id) {
    this.id=id;
}
public Long getId() {
    return id;
}

void setBirthdate(Date date) {
    birthdate = date;
}
public Date getBirthdate() {
    return birthdate;
}

void setWeight(float weight) {
    this.weight = weight;
}
public float getWeight() {
    return weight;
}

public Color getColor() {
    return color;
}
void setColor(Color color) {
    this.color = color;
}

void setSex(char sex) {
    this.sex=sex;
}
public char getSex() {
    return sex;
}

void setLitterId(int id) {
    this.litterId = id;
}
public int getLitterId() {
    return litterId;
}

void setMother(Cat mother) {
    this.mother = mother;
}
public Cat getMother() {
    return mother;
}
void setKittens(Set kittens) {
    this.kittens = kittens;
}
public Set getKittens() {
    return kittens;
}

// addKitten not needed by Hibernate
public void addKitten(Cat kitten) {
    kitten.setMother(this);
kitten.setLitterId( kittens.size() ); 
    kittens.add(kitten);
}

}

The four main rules of persistent classes: 1.Implement a no-argument constructor

Cat has a no-argument constructor. All persistent classes must have a default constructor (which can be non-public) so that Hibernate can instantiate them using Constructor.newInstance(). It is recommended that you have a default constructor with at least package visibility for runtime proxy generation in Hibernate. 2.2. Provide an identifier property (optional)

Cat has a property called id. This property maps to the primary key column of a database table. The property might have been called anything, and its type might have been any primitive type, any primitive "wrapper" type, java.lang.String or java.util.Date. If your legacy database table has composite keys, you can use a user-defined class with properties of these types (see the section on composite identifiers later in the chapter.)

The identifier property is strictly optional. You can leave them off and let Hibernate keep track of object identifiers internally. We do not recommend this, however.

In fact, some functionality is available only to classes that declare an identifier property:

Transitive reattachment for detached objects (cascade update or cascade merge) - see Section 10.11, “Transitive persistence” Session.saveOrUpdate() Session.merge() We recommend that you declare consistently-named identifier properties on persistent classes and that you use a nullable (i.e., non-primitive) type.

3. Prefer non-final classes (optional)

A central feature of Hibernate, proxies, depends upon the persistent class being either non-final, or the implementation of an interface that declares all public methods.

You can persist final classes that do not implement an interface with Hibernate. You will not, however, be able to use proxies for lazy association fetching which will ultimately limit your options for performance tuning.

You should also avoid declaring public final methods on the non-final classes. If you want to use a class with a public final method, you must explicitly disable proxying by setting lazy="false".

4. Declare accessors and mutators for persistent fields (optional)

Cat declares accessor methods for all its persistent fields. Many other ORM tools directly persist instance variables. It is better to provide an indirection between the relational schema and internal data structures of the class. By default, Hibernate persists JavaBeans style properties and recognizes method names of the form getFoo, isFoo and setFoo. If required, you can switch to direct field access for particular properties.

Properties need not be declared public - Hibernate can persist a property with a default, protected or private get / set pair.

Implementing inheritance

A subclass must also observe the first and second rules. It inherits its identifier property from the superclass, Cat. For example:

package eg;

    public class DomesticCat extends Cat {
    private String name;

    public String getName() {
            return name;
    }
    protected void setName(String name) {
            this.name=name;
    }
    } 

Implementing equals() and hashCode()

You have to override the equals() and hashCode() methods if you:

intend to put instances of persistent classes in a Set (the recommended way to represent many-valued associations); and intend to use reattachment of detached instances Hibernate guarantees equivalence of persistent identity (database row) and Java identity only inside a particular session scope. When you mix instances retrieved in different sessions, you must implement equals() and hashCode() if you wish to have meaningful semantics for Sets.

The most obvious way is to implement equals()/hashCode() by comparing the identifier value of both objects. If the value is the same, both must be the same database row, because they are equal. If both are added to a Set, you will only have one element in the Set). Unfortunately, you cannot use that approach with generated identifiers. Hibernate will only assign identifier values to objects that are persistent; a newly created instance will not have any identifier value. Furthermore, if an instance is unsaved and currently in a Set, saving it will assign an identifier value to the object. If equals() and hashCode() are based on the identifier value, the hash code would change, breaking the contract of the Set. See the Hibernate website for a full discussion of this problem. This is not a Hibernate issue, but normal Java semantics of object identity and equality.

It is recommended that you implement equals() and hashCode() using Business key equality. Business key equality means that the equals() method compares only the properties that form the business key. It is a key that would identify our instance in the real world (a natural candidate key):

public class Cat {

...
public boolean equals(Object other) {
    if (this == other) return true;
    if ( !(other instanceof Cat) ) return false;

    final Cat cat = (Cat) other;

    if ( !cat.getLitterId().equals( getLitterId() ) ) return false;
    if ( !cat.getMother().equals( getMother() ) ) return false;

    return true;
}

public int hashCode() {
    int result;
    result = getMother().hashCode();
    result = 29 * result + getLitterId();
    return result;
}

} A business key does not have to be as solid as a database primary key candidate Immutable or unique properties are usually good candidates for a business key.