Object-relational mapping in Java

Generator DataMatrix in Java Object-relational mapping

@Id @GeneratedValue(strategy=GenerationType.TABLE, generator="USER_TABLE_GENERATOR") @Column(name="USER_ID") protected Long userId;

Default primary key generation strategy The last option for key generation is to let the provider decide the best strategy for the underlying database by using the AUTO specification as follows:

@Id @GeneratedValue(strategy=GenerationType.AUTO) @Column(name="USER_ID") protected Long userId;

This is a perfect match for automatic table creation because the underlying database objects required will be created by the JPA provider.

You d assume that if Oracle were the underlying database, the persistence provider probably would choose SEQUENCE as the strategy; if SQL Server were the underlying database, IDENTITY would likely be chosen on your behalf. However, this may not be true, and we recommend that you check the documentation of your persistence provider. For example, TopLink Essentials uses a table generator as the default autogenerator for all databases.

Keep in mind that although generated values are often used for surrogate keys, you could use the feature for any persistence field or property. Before we move on to discussing entity relations, we ll tackle the most complicated case of mapping basic entity data next mapping embeddable objects.

Just as EJB 3 standardizes O/R mapping, it standardizes key generation as well. This is a substantial leap from EJB 2, where you had to resort to various sequence generator patterns to accomplish the same for CMP entity beans. Using sequences, identity constraints, or tables was a significant effort, a far cry from simple configuration, not to mention a nonportable approach.

When discussing embeddable objects in chapter 7, we explained that an embeddable object acts primarily as a convenient data holder for entities and has no

Figure 8.3 Embeddable objects act as convenient data holders for entities and have no identity of their own. Address is an embeddable object that is stored as a part of the User entity that is mapped to the USERS table.

identity of its own. Rather, it shares the identity of the entity class it belongs to. Let s now discuss how embeddable objects are mapped to the database (figure 8.3). In listing 8.4, we included the Address embedded object introduced in chapter 7 in the User entity as a data field. The relevant parts of listing 8.4 are repeated in listing 8.6 for easy reference.

@Table(name="USERS") Table stores both entity and embeddable object ... public class User implements Serializable {

@Id @Column(name="USER_ID", nullable=false) protected Long userId; ... Embedded field @Embedded protected Address address; ...

} ...

@Embeddable public class Address implements Serializable { @Column(name="STREET", nullable=false) protected String street; ... @Column(name="ZIP_CODE", nullable=false) protected String zipCode; ... }

The User entity defines the address field as an embedded object D. Notice that unlike the User entity, the embeddable Address object E is missing an @Table annotation. This is because EJB 3 does not allow embedded objects to be mapped to a table different from the enclosing entity, at least not directly through the @Table annotation. Instead, the Address object s data is stored in the USERS table that stores the enclosing entity b. Therefore, the @Column mappings applied to the fields of the Address object F really refer to the columns in the USERS table. For example, the street field is mapped to the USERS.STREET column, the zipCode field is mapped to the USERS.ZIP_CODE column, and so on. This also means that the Address data is stored in the same database row as the User data, and both objects share the USER_ID identity column C. Other than this minor nuance, all data mapping annotations used in entities are available for you in embedded objects and behave in exactly the same manner. In general, this is the norm and embedded objects are often stored in the same table as the enclosing entity. However, if this does not suit you, it is possible to store the embeddable object s data in a separate table and use the @SecondaryTable annotation to retrieve its data into the main entity using a join. We won t detail this solution, as it is fairly easy to figure out and we ll leave it for you to experiment with instead.