Assoaciation Mappings

Unidirectional associations
  1.  Many-to-one
  2.  One-to-one
  3.  One-to-many
Unidirectional associations with join tables
  1. One-to-many
  2. Many-to-one
  3. One-to-one
  4. Many-to-many
Bidirectional associations
  1. One-to-many / many-to-one
  2. One-to-one
Bidirectional associations with join tables
  1. one-to-many / many-to-one
  2. one to one
  3. Many-to-many
Parent Child Relation Ship


<set name="children" inverse="true" cascade="all-delete-orphan">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>
<many-to-one name="parent" column="parent_id" not-null="true"/>

Parent p = (Parent) session.load(Parent.class, pid);
Child c = new Child();
p.addChild(c);
session.flush();

public void addChild(Child c) {
c.setParent(this);
children.add(c);
}
Inverse: For you, and for Java, a bi-directional link is simply a matter of setting the references on both sides correctly. Hibernate, however, does not have enough information to correctly arrange SQL INSERT and UPDATE statements (to avoid constraint violations). Making one side of the association inverse tells Hibernate to consider it a mirror of the other side. That is all that is necessary for Hibernate to resolve any issues that arise when transforming a directional navigation model to a SQL database schema. The rules are straightforward: all bi-directional associations need one side as inverse. In a one-to-many association it has to be the many-side, and in many-to-many association you can select either side.

Cascade: (optional - defaults to none): cascade enables operations to cascade to child entities.
cascade="all|none|save-update|delete|all-delete-orphan|delete-orphan"
<class
name="Item"
table="ITEM">
...
<set
name="bids"
inverse="true"
cascade="all-delete-orphan">
<key column="ITEM_ID"/>
<one-to-many class="Bid"/>
</set>
</class>
In our case, a we do want it to be deleted. To do this, we must use Child cannot exist without its parent. So if we remove a Child from the collection,cascade="all-delete-orphan". 

We used cascade="all-delete-orphan" to indicate the following:
  • Any newly instantiated Bid becomes persistent if the Bid is referenced by a persistent Item (as was also the case with cascade="save-update"). Any persistent Bid should be deleted if it’s referenced by an Item when the item is deleted.
  • Any persistent Bid should be deleted if it’s removed from the bids collection of a persistent Item. (Hibernate will assume that it was only referenced by this item and consider it an orphan.)
------------------------------------------------------------------------------------------
Fetching strategies
Hibernate uses a fetching strategy to retrieve associated objects if the application needs to navigate the association. Fetch strategies can be declared in the O/R mapping metadata, or over-ridden by a particular HQL or Criteria query.
Hibernate3 defines the following fetching strategies:
  • Join fetching: Hibernate retrieves the associated instance or collection in the same SELECT, using an OUTER JOIN.
  • Select fetching: a second SELECT is used to retrieve the associated entity or collection. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you access the association.
  • Subselect fetching: a second SELECT is used to retrieve the associated collections for all entities retrieved in a previous query or fetch. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you access the association.
  • Batch fetching: an optimization strategy for select fetching. Hibernate retrieves a batch of entity instances or collections in a single SELECT by specifying a list of primary or foreign keys.
Hibernate also distinguishes between:
  • Immediate fetching: an association, collection or attribute is fetched immediately when the owner is loaded.
  • Lazy collection fetching: a collection is fetched when the application invokes an operation upon that collection. This is the default for collections.
  • "Extra-lazy" collection fetching: individual elements of the collection are accessed from the database as needed. Hibernate tries not to fetch the whole collection into memory unless absolutely needed. It is suitable for large collections.
  • Proxy fetching: a single-valued association is fetched when a method other than the identifier getter is invoked upon the associated object.
  • "No-proxy" fetching: a single-valued association is fetched when the instance variable is accessed. Compared to proxy fetching, this approach is less lazy; the association is fetched even when only the identifier is accessed. It is also more transparent, since no proxy is visible to the application. This approach requires buildtime bytecode instrumentation and is rarely necessary.
  • Lazy attribute fetching: an attribute or single valued association is fetched when the instance variable is accessed. This approach requires buildtime bytecode instrumentation and is rarely necessary.
We have two orthogonal notions here: when is the association fetched and how is it fetched. It is important that you do not confuse them. We use fetch to tune performance. We can use lazy to define a contract for what data is always available in any detached instance of a particular class.