The uniqueConstraints element is also not commonly used. In addition, there's no
guarantee this element will be used by your JPA implementation (persistence provider).
Most persistence providers include a great developer-friendly feature known as automatic
schema generation. The persistence provider will automatically create database objects for
your entities when they don't exist in the database. This behavior isn't mandated by the
JPA specification and is configured using vendor-specific properties. The uniqueCon-
straints element tells the persistence provider which columns on the auto-generated
table should have a unique constraint. Again there's no guarantee the persistence provider
will support auto-generation, and if it does, there's no guarantee the uniqueCon-
straints element will be applied.
Outside of a development environment for quick prototyping or unit testing, auto-genera-
tion of tables is almost never a good idea. But if you're working on an open-source project
that requires a database, then auto-generation may allow the software community to get
your application up and running quickly for evaluation purposes. Your application can con-
figure JPA (using the persistence.xml discussed later) to use the EE server's default
data source. This will allow others to deploy your application to their EE servers with little
or no configuration. If you do use the default data source, expect an immediate request for
instructions on configuring your application to use a different one.
Default data source
New to the Java EE 7 specification is a standardization of the JNDI location for the EE
server's default data source. The standard location is defined as
This data source can easily be retrieved with the @Resource tag:
The @Table annotation is limited to specifying a single table. But it's common for rela-
tional databases to store the data you want in multiple tables. Next, we'll look at how you
use the @SecondaryTable annotation to work with two or more tables.