<id name="id" column="ADDRESS_ID">
Using a foreign key association
The easiest way to represent the association from User to its billingAddress is to use a <many-to-one> mapping with a unique constraint on the foreign key. This may surprise you, since many doesn’t seem to be a good description of either end of a one-to-one association! However, from Hibernate’s point of view, there isn’t much difference between the two kinds of foreign key associations. So, we add a foreign key column named BILLING_ADDRESS_ID to the USER table and map it as follows:
Note that we’ve chosen save-update as the cascade style. This means the Address will become persistent when we create an association from a persistent User. Probably, cascade="all" makes sense for this association, since deletion of the User should result in deletion of the Address. (Remember that Address now has its own entity lifecycle.)
Our database schema still allows duplicate values in the BILLING_ADDRESS_ID column of the USER table, so two users could have a reference to the same address. To make this association truly one-to-one, we add unique="true" to the <many-toone> element, constraining the relational model so that there can be only one user per address:
This change adds a unique constraint to the BILLING_ADDRESS_ID column in the DDL generated by Hibernate—resulting in the table structure illustrated by figure 6.7.
But what if we want this association to be navigable from Address to User in Java? From chapter 3, you know how to turn it into a bidirectional one-to-many collection—but we’ve decided that each Address has just one User, so this can’t be the right solution. We don’t want a collection of users in the Address class. Instead, we add a property named user (of type User) to the Address class, and map it like so in the mapping of Address:
This mapping tells Hibernate that the user association in Address is the reverse direction of the billingAddress association in User.
In code, we create the association between the two objects as follows:
Address address = new Address();
address.setStreet("646 Toorak Rd");
Transaction tx = session.beginTransaction();
User user = (User) session.get(User.class, userId);
To finish the mapping, we have to map the homeAddress property of User. This is easy enough: we add another <many-to-one> element to the User metadata, mapping a new foreign key column, HOME_ADDRESS_ID:
The USER table now defines two foreign keys referencing the primary key of the ADDRESS table: HOME_ADDRESS_ID and BILLING_ADDRESS_ID.
Unfortunately, we can’t make both the billingAddress and homeAddress associations bidirectional, since we don’t know if a particular address is a billing address or a home address. (We can’t decide which property name—billingAddress or homeAddress—to use for the property-ref attribute in the mapping of the user property.) We could try making Address an abstract class with subclasses HomeAddress and BillingAddress and mapping the associations to the subclasses. This approach would work, but it’s complex and probably not sensible in this case. Our advice is to avoid defining more than one one-to-one association between any two classes. If you must, leave the associations unidirectional. If you don’t have more than one—if there really is exactly one instance of Address per User—there is an alternative approach to the one we’ve just shown. Instead of defining a foreign key column in the USER table, you can use a primary key association.
Using a primary key association
Two tables related by a primary key association share the same primary key values. The primary key of one table is also a foreign key of the other. The main difficulty with this approach is ensuring that associated instances are assigned the same primary key value when the objects are saved. Before we try to solve this problem, let’s see how we would map the primary key association.
For a primary key association, both ends of the association are mapped using the <one-to-one> declaration. This also means that we can no longer map both the billing and home address, only one property. Each row in the USER table has a corresponding row in the ADDRESS table. Two addresses would require an additional table, and this mapping style therefore wouldn’t be adequate. Let’s call this single address property address and map it with the User:
Next, here’s the user of Address:
The most interesting thing here is the use of constrained="true". It tells Hibernate that there is a foreign key constraint on the primary key of ADDRESS that refers to the primary key of USER.
Now we must ensure that newly saved instances of Address are assigned the same identifier value as their User. We use a special Hibernate identifier-generation strategy called foreign:
<class name="Address" table="ADDRESS">
<id name="id" column="ADDRESS_ID">
The <param> named property of the foreign generator allows us to name a one-toone association of the Address class—in this case, the user association. The foreign generator inspects the associated object (the User) and uses its identifier as the identifier of the new Address. Look at the table structure in figure 6.8. The code to create the object association is unchanged for a primary key association; it’s the same code we used earlier for the many-to-one mapping style.