Single-valued entity associations in Java

Painting QR Code in Java Single-valued entity associations

Let s start with one-to-one entity associations. We argued in chapter 4 that the relationships between User and Address (the user has a billingAddress, homeAddress, and shippingAddress) are best represented with a <component> mapping. This is usually the simplest way to represent one-to-one relationships, because the lifecycle is almost always dependent in such a case, it s either an aggregation or a composition in UML. But what if you want a dedicated table for Address, and you map both User and Address as entities One benefit of this model is the possibility for shared references another entity class (let s say Shipment) can also have a reference to a particular Address instance. If a User has a reference to this instance, as their shippingAddress, the Address instance has to support shared references and needs its own identity. In this case, User and Address classes have a true one-to-one association. Look at the revised class diagram in figure 7.1. The first change is a mapping of the Address class as a stand-alone entity:

<class name="Address" table="ADDRESS"> <id name="id" column="ADDRESS_ID"> <generator .../> </id> <property name="street" column="STREET"/>

We assume you won t have any difficulty creating the same mapping with annotations or changing the Java class to an entity, with an identifier property this is the only change you have to make. Now let s create the association mappings from other entities to that class. There are several choices, the first being a primary key one-to-one association.

Rows in two tables related by a primary key association share the same primary key values. 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 you map the primary key association. Mapping a primary key association with XML The XML mapping element that maps an entity association to a shared primary key entity is <one-to-one>. First you need a new property in the User class:

public class User { ... private Address shippingAddress; // Getters and setters }

Next, map the association in User.hbm.xml:

You add a cascading option that is natural for this model: If a User instance is made persistent, you usually also want its shippingAddress to become persistent. Hence, the following code is all that is needed to save both objects:

User newUser = new User(); Address shippingAddress = new Address(); newUser.setShippingAddress(shippingAddress); session.save(newUser);

Hibernate inserts a row into the USERS table and a row into the ADDRESS table. But wait, this doesn t work! How can Hibernate possibly know that the record in the ADDRESS table needs to get the same primary key value as the USERS row At the beginning of this section, we intentionally didn t show you any primary-key generator in the mapping of Address. You need to enable a special identifier generator. The foreign identifier generator If an Address instance is saved, it needs to get the primary key value of a User object. You can t enable a regular identifier generator, let s say a database sequence. The special foreign identifier generator for Address has to know where to get the right primary key value. The first step to create this identifier binding between Address and User is a bidirectional association. Add a new user property to the Address entity:

public class Address { ... private User user; // Getters and setters }

Map the new user property of an Address in Address.hbm.xml:

This mapping not only makes the association bidirectional, but also, with constrained="true", adds a foreign key constraint linking the primary key of the ADDRESS table to the primary key of the USERS table. In other words, the database guarantees that an ADDRESS row s primary key references a valid USERS primary key. (As a side effect, Hibernate can now also enable lazy loading of users when a shipping address is loaded. The foreign key constraint means that a user has to exist for a particular shipping address, so a proxy can be enabled without hitting the database. Without this constraint, Hibernate has to hit the database to find out if there is a user for the address; the proxy would then be redundant. We ll come back to this in later chapters.) You can now use the special foreign identifier generator for Address objects: