This article, the third in our series on Hibernate, focuses on the life-cycle states of persistent objects and associations. These concepts are put to work with continued development of an application that was created in the first two articles of this series.
Hibernate: Understanding Associations - Associations: What are They? (Page 3 of 4 )
To represent relationships between classes, associations are used. Before going into the details of how Hibernate perceives associations, an understanding of the working of container managed associations is needed. Managed association means that, if a change is made to one end of the association, it will be reflected at the other end.
For example, let's consider the Order table. If it has a one-to-many relationship with the Product table, the Order class will have a one-to-many association with the Product class. So when changes are made to the attributes participating in this association, they will be reflected at the other end automatically. The developer doesn’t have to mange the associations manually.
How Hibernate implements the management of association is different from that of Container Managed Relationships/Associations or CMR generally provided by EJB CMP. In CMR the association is bidirectional, whereas Hibernate treats each association as different. The primary reason is that Hibernate builds its persistence based on Plain Old Java Object or POJO, and in Java associations are unidirectional. Thus Hibernate doesn’t implement CMR. So the associations are unidirectional. In essence it means if the on-update-cascade attribute is set in the mapping for Order and not in Product, any operation on Product would not affect Order.
Keeping these points in mind, let's move on to the different types of associations supported by Hibernate. Hibernate mainly supports two types of associations:
To work with associations, the changes would be required in both the mapping as well as in the persistence class. The details are as follows:
In this kind of association one object of a class is in a relationship with many objects of another class. The class that is having the single instance contains a collection of instances of the other class. To specify this association the mapping file would have to be modified. The added code would be:
The name attribute takes the name of the variable that is participating in the association. The column attribute is used to specify the table column that is participating in the association. The class attribute takes the class name to which this class is associated. In the Persistent class the following change would be there:
//other variable declarations
Set <className> =new HashSet();
//constructors and getter/setter code follows
Then the constructor with the added parameter for Set must be given along with the getter and setter for the Set. In the third section I will be discussing a real world example to illustrate this point.
This is the opposite of the One-to-Many association. In this case, the class that is having a Many-to-One association contains the object of the class. For example, if class A has a Many-to-One association with class B, then each instance of B would have an instance of A. And the identity of this instance can be the same for multiple objects of B. The change in the mapping would be:
The attributes are the same as the case of One-to-Many. In the case of code it would be