EclipseLink JPA 2.1

This page contains a summary of the major features supported in EclipseLink that implements the JPA 2.1 (JSR 338) specification requirements. The features and examples on this page do not represent a complete list. For more information, please see: the JSR 338 page.

Bulk Update

Until JPA 2.1, performing deletes or updates was not available using the Criteria API. Through the
addition of CriteriaUpdate/CriteriaDelete classes, support for bulkupdate/delete queries has now been added.

Update Example

The following example will update the salary and status, of all Employees who make less than 10000$, and give them a raise.

The following Java Persistence query language delete statement is equivalent.

DELETE FROM PhoneNumber p
WHERE p.status = 'out_of_service'

Stored Procedures

JPA specification 2.1 has introduced support for executing Stored Procedure calls. This includes a new
StoredProcedureQuery API and Named Stored Procedure Queries (pre-existing portions of code on the database).

All the stored procedure examples below assume stored procedures already exist on the DB. Stored procedure creation is performed differently on different Databases. All the following example Stored procedure creation is using MySQL syntax (unless otherwise specified).

Alternatively, users can call spq.execute() directly (which is what getResultList() will call behind the scenes). The execute method will return a boolean indicating true if a result set is returned and false otherwise.

boolean result = spq.execute();
if (result == true) {
customers = spq.getResultList();
} else {
// Handle the false for no result set returned, e.g.
throw new RuntimeException("No result set(s) returned from the stored procedure");
}

boolean resultSet = query.setParameter("address_id_v", "1").execute();
if (resultSet) {
// Result sets must be processed first through getResultList() calls.
}
// Once the result sets and update counts have been processed, output parameters are available for processing.
String city = (String) query.getOutputParameterValue("city_v");

A more complex example with multiple result sets using sql result set mappings

Build the query:

This is one example (of many) on how to configure such a query. Queries and result set mappings can be defined solely in annotations or xml or a mix of both. All the metadata can be defined on a single class or split up across many.

JPQL function

The SQL spec and many databases have SQL functions that are not covered by the JPA specification. With the latest JPA
specification the ability to call generic SQL functions was added to the JPQL syntax. The function keyword may be used to invoke
predefined functions or used defined functions.

CDI Entity Listeners

Entity Listeners now support the Contexts and Dependency Injection API (CDI) when used inside a Java EE container. This support allows entity listeners to use CDI to inject objects and also provides support for @PostConstruct and @PreDestroy method calls.

CDI Example

The following example shows how a SessionBean can be injected into an EntityListener

Treat

Allows relationship joins to be treated as a subclass of the join type.

Converters

Provides control over the conversion from an attribute type and value to the corresponding database type and value

DDL generation

In previous versions for JPA, although DDL generation was present it was not standardized or required. JPA 2.1 has added
standardized provider DDL generation and made DDL generation a requirement.

Entity Graphs

Entity graphs are a means to specify the structure of a graph of entities using entity model metadata. This entity graph consists of representations of attributes and in the case of multi-node entity graphs additional entity graphs to represent the related entities. An entity graph can be specified through annotations:

Once constructed or retrieved the entity graphs can then be used as templates for certain EntityManager operations like load and fetch. For instance applying the entity graph as a fetch graph through a query hint will cause EclipseLink to only load those attributes present in the entity graph and unlisted attributes would become fetchType=LAZY.

The entity graph can also be used to force and entity subgraph to be loaded at query time with the query hint "javax.persistence.loadgraph" . When a load graph is applied all listed attributes will be loaded by the query and any unlisted attributes will be loaded based on their mapping fetchType settings.