This tutorial is a complement for Java Persistence Query Language (JPQL) Part I, in which a new techniques of querying should be discovered and learned. Instead of depending on the entities that being retreived upon query for accessing their inner state/association fields, we’ve also would be querying those fields through an advanced techniques of query. This tutorial is intended to cover such these ways of inquiring. Whenever you’ve felt that you have to see the full examples that made before for covering the different associations of JPA you could refer to EclipseLink Tutorial.

Executing the Queries

To avoid code redundancy, we’ve listed a complete execution example that could be used for executing the provided queries that are listed. So, make sure that you are copying the provided query per each subsequent section and paste it in place of queryStr and execute the application to see the result of the suggested query.

[code lang=”java”]
package net.javabeat.eclipselink;

import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
import javax.persistence.Query;
import net.javabeat.eclipselink.data.DriverLicense;
import net.javabeat.eclipselink.data.Employee;
import net.javabeat.eclipselink.data.Phone;

public class JPAImpl {
static EntityManagerFactory factory = null;
static EntityManager em = null;
static {
factory = Persistence.createEntityManagerFactory("EclipseLink-JPA-Installation");
em = factory.createEntityManager();
}

public static void main(String [] args){
// Define a string based query
String queryStr = "Put Examined Query Here";
// Create a Query Using of Entity Manager
Query query = em.createQuery(queryStr);
// Try to fetch single result
try {
Object object = query.getSingleResult();
if(object instanceof Employee){
System.out.println("EmployeeID :: "+((Employee)object).getEmployeeId());
}
else if(object instanceof Phone){
System.out.println("PhoneID :: "+((Phone)object).getPhoneId() + " Owned By the Employee :: " + ((Phone)object).getEmployee().getEmployeeId());
}
else if(object instanceof DriverLicense){
System.out.println("DriverLicenseID :: "+((DriverLicense)object).getLicenseId() + " Owned By the Employee " + ((DriverLicense)object).getEmployee().getEmployeeId());
}
else {
System.out.println("Value Queried Is :: "+object + " :: ");
}
}
catch(Exception e){
// Try to fetch the result list
List<Object> objects = query.getResultList();
// Loop over results
for(Object object : objects){
if(object instanceof Employee){
System.out.println("EmployeeID :: "+((Employee)object).getEmployeeId());
}
else if(object instanceof Phone){
System.out.println("PhoneID :: "+((Phone)object).getPhoneId() + " Owned By the Employee :: " + ((Phone)object).getEmployee().getEmployeeId());
}
else if(object instanceof DriverLicense){
System.out.println("DriverLicenseID :: "+((DriverLicense)object).getLicenseId() + " Owned By the Employee " + ((DriverLicense)object).getEmployee().getEmployeeId());
}
else if(object instanceof Object []){
// loop over the array of objects
Object [] arrayObjects = (Object [])object;

for(Object arrayObject : arrayObjects){
if(arrayObject instanceof Employee){
System.out.print("EmployeeID :: "+((Employee)arrayObject).getEmployeeId());
}
else if(arrayObject instanceof Phone){
System.out.print("PhoneID :: "+((Phone)arrayObject).getPhoneId() + " Owned By the Employee :: " + ((Phone)arrayObject).getEmployee().getEmployeeId() + " :: ");
}
else if(arrayObject instanceof DriverLicense){
System.out.print("DriverLicenseID :: "+((DriverLicense)arrayObject).getLicenseId() + " Owned By the Employee " + ((DriverLicense)arrayObject).getEmployee().getEmployeeId() + " ::");
}
else {
System.out.print("Value Queried Is :: "+arrayObject + " :: ");
}
}
System.out.println("");
}
else {
System.out.println("Value Queried Is :: "+object + " :: ");
}
}

}
}

}
[/code]

• Some minor changes are happened per each executed query for making the messages more desirable in explanation the concept the query is about to clarify.

Using of Identification Variables

The identification variable is a key stone that the next coming topics need it for being clarified, look at the following fragment of code that shows the application of (identification variable) inside the query of JPQL:

[code lang=”java”]
SELECT employee FROM Employee employee
[/code]

• The employee is an identification variable.
• The identification variable is a valid identifier declared in the FROM clause.
• An identification variable must not be reserved identifier or have the same name as any entity in the same persistent unit.
• Identification variables are case sensitive, so the use of employee is differ from using Employee in case the Employee entity doesn’t defined in the same persistent unit.
• An identification variable evaluates to a value of the type of the expression use in declaring the variable.
• The employee evaluates into Employee instance.
• The identification variable does support the composing of Path Expression.

Accessing State/Association Fields By Path Expression

An identification variable followed by the navigation operator (.) and a state field or association field compose a Path Expression.

[code lang=”java”]
SELECT employee.employeeId, phones.phoneNumber FROM Employee employee, employee.phones phones
[/code]

• The employee and phones are two different identification variables.
• The employee.employeeId, phones.phoneNumber compose a Path Expression.
• The type of the path expression is the type computed as a result of navigation, so the type of the state field or association field to which the expression navigates.
• The employee.employeeId computed to an integer value, cause the employeeId is of type int.
• The phones.phoneNumber computed to a String value, cause the phoneNumber is of type String.
• Depending on the navigability, a path expression that leads to an association field or field whose type is an embeddable class may be further composed.
• Path Expression can be composed from other path expressions if the original path expression evaluates to a single-valued type (not a collection).
• An implicit inner joins has been specified at the FROM clause (See Joins Section).

Let’s try navigate the employee identification variable for accessing the phones by using the statement employee.phones.

[code lang=”java”]

SELECT employee.employeeId,employee.phones, phones.phoneNumber FROM Employee employee, employee.phones phones

[/code]

If you’ve executed the previous snippet of code you are surely getting an exception.

Navigating Into Embeddable Class

Let’s try the following the that composed a navigation into Embeddable address field.

[code lang=”java”]
SELECT employee.employeeId,address.addressId.addressId,address.addressId.addressCityId FROM Employee employee, employee.address address
[/code]

• The Path Expression that navigates the address field of Employee does again composed to access those fields inside the Embeddable AddressPK. (See EclipseLink Examples).

Inner Joins

An inner join may be implicitly specified by the use of a cartesian product on the FROM (As you’ve seen before) clause and a join condition in the where clause. In the absence of a join condition, this reduces to the cartesian product. Let’s see the difference between an implicit of inner join and explicit join. But before seeing the result of the samples, we’ve assumed that we have two employees and 3 phones. Employee with an id (1) references two phones and Employee with an id (2) references 1 phone.

Using Implicit JOIN

[code lang=”java”]
SELECT employee.employeeId,phone.phoneId FROM Employee employee, employee.phones phone
[/code]

Using Explicit JOIN

[code lang=”java”]
SELECT employee.employeeId,phone.phoneId FROM Employee employee JOIN employee.phones phone
[/code]

The result of two samples of query should be identical:

[code lang=”java”]
EmployeeID :: 1 :: PhoneID :: 1 ::
EmployeeID :: 1 :: PhoneID :: 2 ::
EmployeeID :: 2 :: PhoneID :: 3 ::
[/code]

• The Java Persistence Query Language (JPQL) does provide an inner join in case the absence of JOIN keyword and if the JOINED entities does provide a foreign key that is mapped to an entity relationship.
• The Implicit Inner Join called (Theta-Join).
• If you’ve removed the JOIN keyword, you will get the same result, cause there is a foreign key between Employee and Phone entities, so an inner JOIN should be specified by the FROM clause and without need for WHERE clause.

Let’s look at the following example that does make a query between Employee and DriverLicense, in that the Employee entity doesn’t provide a direct association of DriverLicense.

[code lang=”java”]
SELECT employee,license FROM Employee employee, DriverLicense license
[/code]

The Result of the previous code is:

[code lang=”java”]
Employee ID :: 1 :: DriverLicense ID :: 26 :: License Owned By Employee :: 1
Employee ID :: 2 :: DriverLicense ID :: 26 :: License Owned By Employee :: 1
[/code]

• Even the DriverLicense of id 26 doesn’t relate anymore to the Employee of ID 2, however the result shows a Cross Join that already made by the JPQL FROM clause.
• The solution for such kind problem is by using the WHERE condition.
• The using of Join condition that specified at the WHERE clause, when a join doesn’t involve a foreign key relationship that is mapped to an entity relationship.

Let’s look at the next coming fragment of code that does provide a WHERE condition.

[code lang=”java”]
SELECT employee,license FROM Employee employee, DriverLicense license
WHERE employee.employeeId = license.employee.employeeId
[/code]

The Result of the previoud code is:

[code lang=”java”]
Employee ID :: 1 :: DriverLicense ID :: 26 :: License Owned By Employee :: 1
[/code]

Left Outer Joins

The LEFT JOIN & LEFT OUTER JOIN are synonymous. They enable the retrieval of a set of entities where matching values in the join condition may be absent.

At the next following example, let we have a two different employees, one of them is associated with two phone objects. let’s querying the database using two different queries.

[code lang=”java”]
SELECT DISTINCT employee.employeeId FROM Employee employee, employee.phones phone
[/code]

The result of the query is

[code lang=”java”]
EmployeeID :: 1 ::
[/code]

• By using the inner join as we have done in the previous query will not give us that employee that’s not associated with any instance of Phone.
• The solution of such that problem is by querying the database by using the LEFT JOIN.

[code lang=”java”]
SELECT DISTINCT employee.employeeId FROM Employee employee LEFT JOIN employee.phones phone
[/code]

The result of the query is

[code lang=”java”]
EmployeeID :: 1 ::
EmployeeID :: 2 ::
[/code]

• The result of the LEFT JOIN is the employees that have a phones and those employees that haven’t a phones.

Queries Using Input Parameters

The following query finds the employee whose ID is designated by an input parameters.

[code lang=”java”]
// Create a parameterized query string
String queryStr = "SELECT employee.employeeId FROM Employee employee WHERE employee.employeeId = ?1";
// Create a Query Using of Entity Manager
Query query = em.createQuery(queryStr);
// Set the parameter by specify the index of the parameter and the value
query.setParameter(1, 1);
[/code]

• To specify a parameter in the query string you have to type a question suffixed by the index of the parameter.
• The query above specify one parameter at the index 1.
• When using a parametrized query, you have to specify the parameter index and parameter value by invoking the setParameter upon Query object.

ORDER BY Clause

We’ve the opportunity to order the result of the query by using ORDER BY reserved keyword. Order By reserved keyword is working in conjunction with ASC and DESC.

[code lang=”java”]
SELECT employee.employeeId,employee.employeeName FROM Employee employee ORDER BY employee.employeeName DESC
[/code]

The result of the query above

[code lang=”java”]
Employee ID Is :: 2 :: Employee Name :: Suza Smith ::
Employee ID Is :: 1 :: Employee Name :: Gilbert Samouel ::
[/code]

• The ORDER BY clause allows objects or values that are returned by the query to be ordered.
• The keyword ASC specifies that ascending ordering, while the DESC specifies that descending ordering.
• Ascending order is the default ordering.

Summary

Java Persistence Query Language (JPQL), provides a lot of techniques for doing a query. Identification Variables, Path Expressions, Inner Joins, Left Joins and other concept are introduced at this tutorial.

Eclipselink 2.1 is a persistence provider runtime of the Java Persistence API 2.1 specification. JPA  specification defines two major strategies of loading data (Lazy and Eager). The EAGER strategy is a requirement on the persistence provider runtime that data must be eagerly fetched. The LAZY strategy is a hint to the persistence provider runtime that data should be fetched lazily when it is first time accessed.

The Lazy loading is commonly used to defer the loading of the attributes or associations of an entity or entities until the point at which they are needed, meanwhile the eager loading is an opposite concept in which the attributes and associations of an entity or entities are fetched explicitly and without any need for pointing them.

Determine The Loading Strategy

EclipseLink 2.1 provides you different ways to mention your desired loading strategy.

• Basic Annotation: It provides a fetchType attribute that can be used for determining the strategy to which the attribute(s) that should be loaded eagerly or lazily.
• @OneToOne, @ManyToOne, @OneToMany and @ManyToMany: Every associations annotations provide fetchType attribute that can be used for determining the strategy to which the attributes(s) that should be loaded eagerly or lazily.

Lazy Fetch Type With @OneToOne and @ManyToOne

If you’ve noted before @OneToOne association example, you’ve absolutely seen the association between Employee and Address entities adhered a bidirectional OneToOne. It’s the time to give more attention about Eager and Lazy loading in that association. Let’s see what’s the role that can fetchType attribute play in this association when it used at the Employee side and at the Address side. (see EclipseLink Tutorials)

The default value of fetchType attribute within OneToOne annotation is an eager value, and whether the value of the field or property should be lazily loaded or must be eagerly fetched. The EAGER strategy is a requirement on the persistence provider runtime that the value must be eagerly fetched and the LAZILY is just a hint to the persistence provider runtime.

By default EclipseLink consider the OneToOne and ManyToOne associations as not lazily associations. So if we’ve set OneTOne or ManyToOne associations to lazy without using of EclipseLink weaving, we surely have an eager association. Let’s see Figure 1.0 that shows you an Employee entity associated with an Address entity in a OneToOne association.

Employee.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import java.util.List;

import javax.persistence.Basic;
import javax.persistence.CascadeType;
import javax.persistence.DiscriminatorColumn;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Embedded;
import javax.persistence.Entity;
import javax.persistence.EntityListeners;
import javax.persistence.FetchType;
import javax.persistence.Id;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
import javax.persistence.JoinColumn;
import javax.persistence.JoinColumns;
import javax.persistence.JoinTable;
import javax.persistence.ManyToMany;
import javax.persistence.OneToMany;
import javax.persistence.OneToOne;

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name="EmployeeType")
@DiscriminatorValue(value="EMP")
@EntityListeners(value={PersistenceContextListener.class})
public class Employee {

@Id
private int employeeId;

@Basic(optional=false)
private String employeeName;

@Embedded
private EmployeePeriod employeePeriod;

@OneToMany(mappedBy="employee", cascade=CascadeType.ALL,fetch=FetchType.EAGER)
private List phones;

@ManyToMany(cascade=CascadeType.ALL,fetch=FetchType.EAGER)
@JoinTable(
name="employee_project",
joinColumns={@JoinColumn(name="employeeId")},
inverseJoinColumns={
@JoinColumn(table="project",name="projectId"),
@JoinColumn(table="localproject",name="projectId"),
@JoinColumn(table="globalproject",name="projectId")}
)
private List projects;

@OneToOne(cascade={CascadeType.ALL},fetch=FetchType.LAZY,targetEntity=Address.class)
@JoinColumns({
@JoinColumn(name="AddressId",referencedColumnName="AddressId"),
@JoinColumn(name="EmployeeAddressCountryId",referencedColumnName="AddressCountryId"),
@JoinColumn(name="EmployeeAddressCityId",referencedColumnName="AddressCityId")}
)
private Address address; // Note: OneToOne annotation is configured as lazy loading

public Address getAddress() {
return address;
}

public void setAddress(Address address) {
this.address = address;
}

public int getEmployeeId() {
return employeeId;
}

public void setEmployeeId(int employeeId) {
this.employeeId = employeeId;
}

public String getEmployeeName() {
return employeeName;
}

public void setEmployeeName(String employeeName) {
this.employeeName = employeeName;
}

public List getPhones() {
return phones;
}

public void setPhones(List phones) {
this.phones = phones;
}

public List getProjects() {
return projects;
}

public void setProjects(List projects) {
this.projects = projects;
}

public EmployeePeriod getEmployeePeriod() {
return employeePeriod;
}

public void setEmployeePeriod(EmployeePeriod employeePeriod) {
this.employeePeriod = employeePeriod;
}

}

[/code]

Address.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import javax.persistence.CascadeType;
import javax.persistence.EmbeddedId;
import javax.persistence.Entity;
import javax.persistence.EntityListeners;
import javax.persistence.FetchType;
import javax.persistence.OneToOne;
import javax.persistence.PrePersist;

@Entity(name="address")
@EntityListeners(value={PersistenceContextListener.class})
public class Address {
@EmbeddedId
private AddressPK addressId;
private String addressCountry;
private String addressCity;

@OneToOne(cascade=CascadeType.ALL,mappedBy="address",fetch=FetchType.LAZY)
private Employee employee; // Note: The OneToOne association is configured as lazy loading

public Employee getEmployee() {
return employee;
}

public void setEmployee(Employee employee) {
this.employee = employee;
}

public String getAddressCountry() {
return addressCountry;
}
public void setAddressCountry(String addressCountry) {
this.addressCountry = addressCountry;
}
public String getAddressCity() {
return addressCity;
}
public void setAddressCity(String addressCity) {
this.addressCity = addressCity;
}

public AddressPK getAddressId() {
return addressId;
}

public void setAddressId(AddressPK addressId) {
this.addressId = addressId;
}

@PrePersist
public void prePersist(){
System.out.println("Address Entity :: Method PrePersist Invoked Upon Entity "+this);
}

}

[/code]

Let’s we execute the following snippet of code:

[code lang=”java”]

Employee emp = em.find(Employee.class, 1);

[/code]

• The executed sample code assumed that an employee row instance has been persisted previously. (See OneToOne Association).
• The Eclipselink implementation will discard the hint that you’ve set that the fetch type is lazy.
• The Address OneToOne mapping will be fetched as an Eager loading. See Figure 1.0 that shows you the instance of Employee and its dependent objects.

Figure 1.0

As you’ve noted in the Figure 1.0

• The Address entity has fetched by the EclipseLink JPA, although the fetch type of Address is lazy.
• By default, EclipseLink discard the fetch Type lazy in case we’ve used the @OneToOne and @ManyToOne.

Enforce EclipseLink To Consider Lazy Associations

To enforce EclipseLink considering the Lazy fetch type that passed in the previous Employee sample, we have to use what Eclipse named “Weaved Indirection”.

If we set OneToOne or ManyToOne associations are lazy, we enable weaving, the EclipseLink JPA persistence provider will use weaving to enable value holder indirection for these associations. Before any further next lines let’s see how could we enable weaving using Eclipse IDE and by using the same provided examples.

• Determine the eclipselink.jar that contains the weaving required API (See EclipseLink Installation And Configuration Using Eclipse)
• Open EclipseIDE.
• Open EclipseLink – JPA-Installation package
• Determine you executable class (At this example it will be JPAImpl.java).
• Set a break point at that line code that fetched Employee instance from a database.
• Click on the Run menu from the top main menu.
• Select Debug Configuration.
• From the window opened and from the left side select the Java Application that you would use for weaving.
• From the same window, but at the right side select the titled tab (Arguments).
• Inside the VM arguments box type (-javaagent:eclipselink.jar).
• From the Working Directory beneath the VM arguments box select Other.
• Specify the eclipselink.jar file by navigating into the installed EclipseLink Installation file. See Figure 1.1 that shows you the final image of what you should have on your local environment.

Figure 1.1

• Close the dialog by clicking on the Debug.
• You should see the JPAImpl.java is executing and the debug stopped in at the break point that already defined.
• Click F6 for proceed one step forward.
• Let your mouse curser move over the emp instance.
• The EclipseIDE must display the emp instance and all of its dependent objects, but that’s time with respective for those mapping that defined as LAZY LOADING. See Figure 1.2.

Figure 1.2

• Eclipselink uses the indirection; the indirection is likely that a graph of persistent objects that contain (UN triggered) indirection objects.
• EclipseLink uses weaving to implement lazy fetching for OneToOne and ManyToOne associations.
• If you’ve selected the value holder that represents the address instance that named  (_persistence_address_vh=UnitOfWorkQueryValueHolder) than you should see the following message shown below {UnitOfWorkQueryValueHolder: not instantiated}
• Try to investigate the address value holder for seeing the other attributes such as isLazy (true), isInstantiated(false) and others.
• Also, the address attribute that belongs to employee instance is referring to null. See Figure 1.3.

Figure 1.3

• Address instance that belongs to Employee is Null, cause the fetch type that has been selected is Lazy load for achieving such that association.The only way that permitted for accessing the address is by calling it directly. See Figure 1.4.

Figure 1.4

• As you’ve noted the address instance that belongs to Employee does respond now.

By Default EclipseLink Support Lazy Load for @OneToMany and @ManyToMany

Let’s look at the Employee entity and its dependent either objects (Projects and Phones), where the Employee does associate with the Projects as ManyToMany and it does associate with Phones as OneToMany. Let’s see how could be achieving lazy load easily as opposite of using it with OneToOne and ManyToOne.

Employee.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import java.util.List;

import javax.persistence.Basic;
import javax.persistence.CascadeType;
import javax.persistence.DiscriminatorColumn;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Embedded;
import javax.persistence.Entity;
import javax.persistence.EntityListeners;
import javax.persistence.FetchType;
import javax.persistence.Id;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
import javax.persistence.JoinColumn;
import javax.persistence.JoinColumns;
import javax.persistence.JoinTable;
import javax.persistence.ManyToMany;
import javax.persistence.OneToMany;
import javax.persistence.OneToOne;

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name="EmployeeType")
@DiscriminatorValue(value="EMP")
@EntityListeners(value={PersistenceContextListener.class})
public class Employee {

@Id
private int employeeId;

@Basic(optional=false)
private String employeeName;

@Embedded
private EmployeePeriod employeePeriod;

@OneToMany(mappedBy="employee", cascade=CascadeType.ALL,fetch=FetchType.LAZY)
private List phones; // OneToMany lazy Load Association

@ManyToMany(cascade=CascadeType.ALL,fetch=FetchType.LAZY)
@JoinTable(
name="employee_project",
joinColumns={@JoinColumn(name="employeeId")},
inverseJoinColumns={
@JoinColumn(table="project",name="projectId"),
@JoinColumn(table="localproject",name="projectId"),
@JoinColumn(table="globalproject",name="projectId")}
)
private List projects; // ManyToMany Lazy Load Association

@OneToOne(cascade={CascadeType.ALL},fetch=FetchType.LAZY,targetEntity=Address.class)
@JoinColumns({
@JoinColumn(name="AddressId",referencedColumnName="AddressId"),
@JoinColumn(name="EmployeeAddressCountryId",referencedColumnName="AddressCountryId"),
@JoinColumn(name="EmployeeAddressCityId",referencedColumnName="AddressCityId")}
)
private Address address;

public Address getAddress() {
return address;
}

public void setAddress(Address address) {
this.address = address;
}

public int getEmployeeId() {
return employeeId;
}

public void setEmployeeId(int employeeId) {
this.employeeId = employeeId;
}

public String getEmployeeName() {
return employeeName;
}

public void setEmployeeName(String employeeName) {
this.employeeName = employeeName;
}

public List getPhones() {
return phones;
}

public void setPhones(List phones) {
this.phones = phones;
}

public List getProjects() {
return projects;
}

public void setProjects(List projects) {
this.projects = projects;
}

public EmployeePeriod getEmployeePeriod() {
return employeePeriod;
}

public void setEmployeePeriod(EmployeePeriod employeePeriod) {
this.employeePeriod = employeePeriod;
}

}

[/code]

• Employee Entity does consider two additional associations one of type OneToMany with Phone entity and the second is ManyToMany with the Project entity.
• By default EclipseLink does consider the lazy loading of such these associations, so no need for any further configuration as we’ve seen in the OneToOne and ManyToOne. See Figure 1.6 that shows you how can we achieve a lazy load easily.

Figure 1.6

• EclipseLink capable to lazy load either ManyToMany and OneToMany without any need for weaving.
• The list of Phone entities does loaded lazily, cause it’s mapping marked as Lazy fetch type at the Employee entity.
• The list of Project entities does loaded lazily, cause it’s mapping marked as Lazy fetch type at the Employee entity.
• Each Lazy Loading mapping can be navigated by accessing the attribute for which the mapping belongs to.

Navigating ManyToMany and OneToMany Lazy Load

By executing the following code, you have a chance to navigate those lazily loaded mappings:

[code lang=”java”]

Employee employee = em.find(Employee.class, 1);
System.out.println("Phones Size :: "+ employee.getPhones().size());
System.out.println("Projects Size :: "+ employee.getProjects().size());

[/code]

• Once you’ve been accessing the attribute that does relate to the mapping the EclipseLink will fetch the dependent objects directly.

The next coming fragment of output shows you the results in of executing the last code:

[code lang=”java”]

Phones Size :: 1
Projects Size :: 2

[/code]

Eager Loading

As we’ve mentioned previously, the Eager strategy is a requirement on the persistence provider runtime, in that the value must be eagerly fetched. Let’s look at the Employee entity in case the ManyToMany and OneToMany annotation have been changed to be fetched eagerly.

Employee.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import java.util.List;

import javax.persistence.Basic;
import javax.persistence.CascadeType;
import javax.persistence.DiscriminatorColumn;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Embedded;
import javax.persistence.Entity;
import javax.persistence.EntityListeners;
import javax.persistence.FetchType;
import javax.persistence.Id;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
import javax.persistence.JoinColumn;
import javax.persistence.JoinColumns;
import javax.persistence.JoinTable;
import javax.persistence.ManyToMany;
import javax.persistence.OneToMany;
import javax.persistence.OneToOne;

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name="EmployeeType")
@DiscriminatorValue(value="EMP")
@EntityListeners(value={PersistenceContextListener.class})
public class Employee {

@Id
private int employeeId;

@Basic(optional=false)
private String employeeName;

@Embedded
private EmployeePeriod employeePeriod;

@OneToMany(mappedBy="employee", cascade=CascadeType.ALL,fetch=FetchType.EAGER)
private List phones; // OneToMany Eager Load Association

@ManyToMany(cascade=CascadeType.ALL,fetch=FetchType.EAGER)
@JoinTable(
name="employee_project",
joinColumns={@JoinColumn(name="employeeId")},
inverseJoinColumns={
@JoinColumn(table="project",name="projectId"),
@JoinColumn(table="localproject",name="projectId"),
@JoinColumn(table="globalproject",name="projectId")}
)
private List projects; // ManyToMany EAGER Load Association

@OneToOne(cascade={CascadeType.ALL},fetch=FetchType.LAZY,targetEntity=Address.class)
@JoinColumns({
@JoinColumn(name="AddressId",referencedColumnName="AddressId"),
@JoinColumn(name="EmployeeAddressCountryId",referencedColumnName="AddressCountryId"),
@JoinColumn(name="EmployeeAddressCityId",referencedColumnName="AddressCityId")}
)
private Address address;

public Address getAddress() {
return address;
}

public void setAddress(Address address) {
this.address = address;
}

public int getEmployeeId() {
return employeeId;
}

public void setEmployeeId(int employeeId) {
this.employeeId = employeeId;
}

public String getEmployeeName() {
return employeeName;
}

public void setEmployeeName(String employeeName) {
this.employeeName = employeeName;
}

public List getPhones() {
return phones;
}

public void setPhones(List phones) {
this.phones = phones;
}

public List getProjects() {
return projects;
}

public void setProjects(List projects) {
this.projects = projects;
}

public EmployeePeriod getEmployeePeriod() {
return employeePeriod;
}

public void setEmployeePeriod(EmployeePeriod employeePeriod) {
this.employeePeriod = employeePeriod;
}

}

[/code]

See Figure 1.7 that shows you the impact of using Eager.

Figure 1.7

• Each dependent objects are fetched eagerly without need for accessing the attributes.
• The Address is already fetched eagerly, cause we’ve removed the eclipselink weaving that could be used for enabling the OneToOne and ManyToOne lazy loading. Whenever such that Weaving is omitted, the Eclipselink persistence provider will load those assoications (OneToOne and ManyToOne) eagerly.

Using @Baisc To Provide Fetch Type

Typically, the using @Basic for providing a fetch type value is identical to what you’ve seen when it comes to provide such that value using one of the association annotations. But remember that @Basic couldn’t be used on a non-primitive data types (Also, other types is permitted to be used with the @Basic).

You can experienced using of @Basic on the employeeName and see the different if you’ve enabled the weaving. absolutely, you will get the same result as you did see.

Summary

The Lazy and Eager load are strategies considered by the Persistence Provider for optimizing the performance of the developed applications especially, those that could maintain a huge amount of objects and their associations. Lazy load strategy is a hint for persistence provider runtime to defer the fetching of associated objects until the accessing of the related attributes took place. At the other hand the Eager strategy, in that the associated objects are fetched directly. Java Persistence API provides you two different ways to determine the fetch type either @Basic or using of one of the association annotations (OneToOne, OneToMany, ManyToOne and ManyToMany).

Before JPA 2.1 the concept of Entity Listeners (Injectable EntityListeners) wasn’t defined until JPA 2.1 released. The entity listener concept allows the programmer to designate a methods as a lifecycle callback methods to receive notification of entity lifecycle events. A lifecycle callback methods can be defined on an entity class, a mapped superclass, or an entity listener class associated with an entity or mapped superclass.

Default entity listeners are entity listeners whose callback methods has been called by all entities that are defined in a certain persistence context (unit).  The lifecycle callback methods and entity listeners classes can be defined by using metadata annotations or by an XML descriptor.

Entity Listener (Default Listener) Using Entity Listener Class

If you’ve looked before for the introduction examples for eclipselink (See EclipseLink Tutorial), it’s time to listening about events that thrown by lifecycle of the entities. Let’s look at the first entity listener that would be listening for each defined entities in the persistence.xml.

PersistenceContextListener.java

[code lang=”java”]
package net.javabeat.eclipselink.data;

import javax.persistence.PostPersist;
import javax.persistence.PostRemove;
import javax.persistence.PostUpdate;
import javax.persistence.PrePersist;
import javax.persistence.PreRemove;
import javax.persistence.PreUpdate;

public class PersistenceContextListener {
@PrePersist
public void prePersist(Object object) {
System.out.println("PersistenceContextListener :: Method PrePersist Invoked Upon Entity :: " + object);
}

@PostPersist
public void postPersist(Object object){
System.out.println("PersistenceContextListener :: Method PostPersist Invoked Upon Entity :: " + object);
}

@PreRemove
public void PreRemove(Object object){
System.out.println("PersistenceContextListener :: Method PreRemove Invoked Upon Entity :: " + object);
}

@PostRemove
public void PostRemove(Object object){
System.out.println("PersistenceContextListener :: Method PostRemove Invoked Upon Entity :: " + object);
}

@PreUpdate
public void PreUpdate(Object object){
System.out.println("PersistenceContextListener :: Method PreUpdate Invoked Upon Entity :: " + object);
}

@PostUpdate
public void PostUpdate(Object object){
System.out.println("PersistenceContextListener :: Method PostUpdate Invoked Upon Entity :: " + object);
}

}
[/code]

• Entity lifecycle callback methods can be defined on an entity listener class.
• Lifecycle callback methods are annotated with annotation that specifying the callback events for which they are invoked.
• Callback methods defined on an entity listener class should have the following signatures: void <METHOD> (Object), the object argument is the entity class for which the callback method is invoked.
• The callback methods can have public, private, protected or package level access, but must not be static or final.
• The following annotations designates lifecycle event callback methods of the corresponding types (entities).

1. PrePersist: This callback method is invoked for a given entity before the respective Entity Manager executes persist operation for that entity.
2. PostPersist: This callback method is invoked for a given entity after the respective Entity Manager executes persist operation for that entity.
3. PreRemove: This callback method is invoked for a given entity before the respective Entity Manager executes remove operation for that entity. 
4. PostRemove: This callback method is invoked for a given entity after the respective Entity Manager executes remove operation for that entity.
5. PreUpdate: This callback method is invoked for a given entity before the respective Entity Manager executes merge operation for that entity.
6. PostUpdate: This callback method is invoked for a given entity after the respective Entity Manager executes merge operation for that entity.
7. PostLoad: The PostLoad method for an entity is invoked after the entity has been loaded into the current persistence context from the database or after the refresh operation has been applied to it.

The Entity & Mapped SuperClass With Listener

After we’ve seen a separate entity listener, let’s see a listener that could be defined at the entity itself.

Address.java

[code lang=”java”]
package net.javabeat.eclipselink.data;

import javax.persistence.CascadeType;
import javax.persistence.EmbeddedId;
import javax.persistence.Entity;
import javax.persistence.OneToOne;
import javax.persistence.PrePersist;

@Entity(name="address")
public class Address {
@EmbeddedId
private AddressPK addressId;
private String addressCountry;
private String addressCity;

@OneToOne(cascade=CascadeType.ALL,mappedBy="address")
private Employee employee;

public Employee getEmployee() {
return employee;
}

public void setEmployee(Employee employee) {
this.employee = employee;
}

public String getAddressCountry() {
return addressCountry;
}
public void setAddressCountry(String addressCountry) {
this.addressCountry = addressCountry;
}
public String getAddressCity() {
return addressCity;
}
public void setAddressCity(String addressCity) {
this.addressCity = addressCity;
}

public AddressPK getAddressId() {
return addressId;
}

public void setAddressId(AddressPK addressId) {
this.addressId = addressId;
}

@PrePersist
public void prePersist(){
System.out.println("Address Entity :: Method PrePersist Invoked Upon Entity "+this);
}

}

[/code]

License.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import javax.persistence.CascadeType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
import javax.persistence.MappedSuperclass;
import javax.persistence.PostRemove;
import javax.persistence.PrePersist;
import javax.persistence.PreRemove;
import javax.persistence.TableGenerator;

@MappedSuperclass
public abstract class License {

@Id
@GeneratedValue(generator="LICENSE_SEQ",strategy=GenerationType.SEQUENCE)
@TableGenerator(name="LICENSE_SEQ",pkColumnName="SEQ_NAME",valueColumnName="SEQ_NUMBER",pkColumnValue="LICENSE_ID",allocationSize=1,table="sequences")
protected int licenseId;

@ManyToOne(cascade = CascadeType.ALL)
@JoinColumn(name = "employeeId")
private Employee employee;

public Employee getEmployee() {
return employee;
}

public void setEmployee(Employee employee) {
this.employee = employee;
}

public int getLicenseId() {
return licenseId;
}

public void setLicenseId(int licenseId) {
this.licenseId = licenseId;
}

@PrePersist
public void prePersist(){
System.out.println("License Entity :: Method PrePersist Invoked Upon Entity "+this);
}

@PreRemove
public void peRemove(){
System.out.println("License Entity :: Method PreRemove Invoked Upon Entity "+this);
}

@PostRemove
public void postRemove(){
System.out.println("License Entity :: Method PostRemove Invoked Upon Entity "+this);
}
}

[/code]

• Entity lifecycle callback methods can be defined on an entity class.
• Lifecycle callback methods are annotated with annotation that specifying the callback events for which they are invoked within the defined entity.
• Callback methods defined on an entity listener class should have the following signatures: void <METHOD> ().
• The callback methods can have public, private, protected or package level access, but must not be static or final.
• The annotations that designate for achieving the listening for the entity lifecycle events are the same for those defined in the entity listener class that defined above.
• The definition of the lifecycle events callback methods are the same as defined in the mapped superclass as license mapped superclass depicted.

Persistence Configuration

[code lang=”xml”]
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
<persistence-unit name="EclipseLink-JPA-Installation" transaction-type="RESOURCE_LOCAL">
<class>net.javabeat.eclipselink.data.Employee</class>
<class>net.javabeat.eclipselink.data.Address</class>
<class>net.javabeat.eclipselink.data.AddressPK</class>
<class>net.javabeat.eclipselink.data.License</class>
<class>net.javabeat.eclipselink.data.DriverLicense</class>
<properties>
<property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/JavaBeat"/>
<property name="javax.persistence.jdbc.user" value="root"/>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="javax.persistence.jdbc.password" value="root"/>
<property name="eclipselink.logging.level" value="OFF"/>
</properties>
</persistence-unit>
</persistence>
[/code]

Executable Application

[code lang=”java”]

package net.javabeat.eclipselink;

import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

import net.javabeat.eclipselink.data.Address;
import net.javabeat.eclipselink.data.AddressPK;
import net.javabeat.eclipselink.data.ContractDeveloper;
import net.javabeat.eclipselink.data.Developer;
import net.javabeat.eclipselink.data.DriverLicense;
import net.javabeat.eclipselink.data.Employee;
import net.javabeat.eclipselink.data.EmployeePeriod;
import net.javabeat.eclipselink.data.FreelanceDeveloper;
import net.javabeat.eclipselink.data.GlobalProject;
import net.javabeat.eclipselink.data.ICDLComputerLicense;
import net.javabeat.eclipselink.data.License;
import net.javabeat.eclipselink.data.LocalProject;
import net.javabeat.eclipselink.data.Phone;
import net.javabeat.eclipselink.data.PhonePK;
import net.javabeat.eclipselink.data.Project;

public class JPAImpl {
static EntityManagerFactory factory = null;
static EntityManager em = null;
static {
factory = Persistence.createEntityManagerFactory("EclipseLink-JPA-Installation");
em = factory.createEntityManager();
}

public static void main(String [] args){
// Begin a Transaction for creation
em.getTransaction().begin();
// Find the Employee
Employee employee = createEmployee();
// Find the Employee
License license = createDriverLicense(employee);
// Commit
em.getTransaction().commit();

// Begin a Transaction for Update an Employee
em.getTransaction().begin();
// Find the Employee
employee.setEmployeeName("Edward Halshmit");
em.merge(employee);
// Commit
em.getTransaction().commit();

// Begin a Transaction for removing an employee and driver license
em.getTransaction().begin();
// Remove License
em.remove(license);
// Find the Employee
em.remove(employee);
// Commit
em.getTransaction().commit();

}

public static Employee createEmployee(){
// Create an address entity
Address address = new Address();
AddressPK addressPk = new AddressPK();
addressPk.setAddressCountryId(1);
addressPk.setAddressId(1);
address.setAddressId(addressPk);
// Address Embeddable class (Type) instantiation
address.setAddressCountry("United Kingdom");
address.setAddressCity("London");
// Create an employee entity
Employee employee = new Employee();
employee.setEmployeeId(1);
employee.setEmployeeName("John Smith");

// Create an Employee Period Instance
EmployeePeriod period = new EmployeePeriod();
period.setStartDate(new Date());
period.setEndDate(new Date());

employee.setEmployeePeriod(period);

// Associate the address with the employee
employee.setAddress(address);
// Create a Phone entity
Phone firstPhone = new Phone();
// PhoneId and PhoneCountryKeyId is now the primary key for the phone entity
firstPhone.setPhoneId(1);
firstPhone.setPhoneCountryKeyId("+441");
firstPhone.setPhoneNumber("4050 615");
firstPhone.setEmployee(employee);
// Create a list of phone
List phones = new ArrayList();
phones.add(firstPhone);

// Create a list of projects
List projects = new ArrayList();

// Set the project into employee
employee.setProjects(projects);
// Set the phones into your employee
employee.setPhones(phones);

// Persist the employee

em.persist(employee);

// return the persisted employee
return employee;
}

public static License createDriverLicense(Employee employee){
DriverLicense license = new DriverLicense(); // Create a driver license
license.setDriverLicenseName("All Vehicles License"); // Set License Name
license.setDriverLicenseIssueDate(new Date()); // Anonymous date
license.setDriverLicenseExpiryDate(new Date()); // Anonymous date
license.setEmployee(employee);
em.persist(license);
return license;
}

}

[/code]

The Rules Applied on the Lifecycle Callback Methods

The following rules apply to lifecycle callback methods:

• Lifecycle callback methods may throw unchecked/runtime exceptions. A runtime exception thrown by a callback method that executes within a transaction causes that transaction to be marked for rollback if the persistence context is joined to the transaction.
• Lifecycle callbacks can invoke JNDI, JDBC, JMS and enterprise beans.
• In general, the lifecycle method of a portable application should not invoke EntityManager or query oprtations, access other instancesm or modify relationships within the same persistence context. A lifecycle callback methods may modify the non-relationship state of the entity on which it is invoked.

Precedence of Listeners Execution

The precedence of listeners execution are arranged as following:

• Default Listener will be executed firstly, default listener apply to all entities in the persistence unit, so  if you’ve defined multiple listeners within @EntityListener as you’ve seen in the Employee entity, then the callback methods are invoked in the order as listener specified Unless explicitly excluded by means of the ExecludedDefaultListeners annotation.
• The callback methods that are defined within the entity or mapped superclasses themselves should be executed after default listener and in the same order.
• If multiple classes in an inheritance hierarchy (entity classes or mapped superclasses) define entity listeners, the listeners defined in the superclasses are invoked before the listeners defined for its sub-classes.

The Result of Executable Application

[code lang=”java”]

PersistenceContextListener :: Method PrePersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@d5d4de6
Address Entity :: Method PrePersist Invoked Upon Entity net.javabeat.eclipselink.data.Address@6e92b1a1
License Entity :: Method PrePersist Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@47f08ed8
PersistenceContextListener :: Method PostPersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@d5d4de6
PersistenceContextListener :: Method PreUpdate Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@d5d4de6
PersistenceContextListener :: Method PostUpdate Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@d5d4de6
License Entity :: Method PreRemove Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@47f08ed8
PersistenceContextListener :: Method PreRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@d5d4de6
License Entity :: Method PostRemove Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@47f08ed8
PersistenceContextListener :: Method PostRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@d5d4de6

[/code]

What if we’ve changed the License and Address entities by allowing them defining an @EntityListener at their declaration to reference the PersistenceContextListener as you’ve seen at the Employee entity.

The Result of Executable Application After last changed

[code lang=”java”]

PersistenceContextListener :: Method PrePersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@343aff84
PersistenceContextListener :: Method PrePersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Address@301db5ec
Address Entity :: Method PrePersist Invoked Upon Entity net.javabeat.eclipselink.data.Address@301db5ec
PersistenceContextListener :: Method PrePersist Invoked Upon Entity :: net.javabeat.eclipselink.data.DriverLicense@77546dbc
License Entity :: Method PrePersist Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@77546dbc
PersistenceContextListener :: Method PostPersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Address@301db5ec
PersistenceContextListener :: Method PostPersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@343aff84
PersistenceContextListener :: Method PostPersist Invoked Upon Entity :: net.javabeat.eclipselink.data.DriverLicense@77546dbc
PersistenceContextListener :: Method PreUpdate Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@343aff84
PersistenceContextListener :: Method PostUpdate Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@343aff84
PersistenceContextListener :: Method PreRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.DriverLicense@77546dbc
License Entity :: Method PreRemove Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@77546dbc
PersistenceContextListener :: Method PreRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@343aff84
PersistenceContextListener :: Method PreRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Address@301db5ec
PersistenceContextListener :: Method PostRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.DriverLicense@77546dbc
License Entity :: Method PostRemove Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@77546dbc
PersistenceContextListener :: Method PostRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@343aff84
PersistenceContextListener :: Method PostRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Address@301db5ec

[/code]

Inheritance of Callback Lifecycle Methods

The inheritance of callback lifecycle methods is applicable, so a lifecycle callback method for the same lifecycle event is also specified on the entity class or one or more of its entity or mapped superclasses, the callback methods on the entity class or superclasses are invoked first.

The sub-classes are permitted to override an inherited callback method of the same callback type (i.e. override the same method of superclass in the sub-class using the same annotation type), at this case the overridden method isn’t invoked. Let’s see the DriverLicense that override the prePersist method annotated with the same callback type (@PrePersist)

DriverLicense.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import java.util.Date;

import javax.persistence.Entity;
import javax.persistence.PrePersist;
import javax.persistence.Table;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;

@Entity
@Table(name="driverlicenses")
public class DriverLicense extends License{

private String driverLicenseName;
@Temporal(TemporalType.DATE)
private Date driverLicenseExpiryDate;
@Temporal(TemporalType.DATE)
private Date driverLicenseIssueDate;

public String getDriverLicenseName() {
return driverLicenseName;
}
public void setDriverLicenseName(String driverLicenseName) {
this.driverLicenseName = driverLicenseName;
}
public Date getDriverLicenseExpiryDate() {
return driverLicenseExpiryDate;
}
public void setDriverLicenseExpiryDate(Date driverLicenseExpiryDate) {
this.driverLicenseExpiryDate = driverLicenseExpiryDate;
}
public Date getDriverLicenseIssueDate() {
return driverLicenseIssueDate;
}
public void setDriverLicenseIssueDate(Date driverLicenseIssueDate) {
this.driverLicenseIssueDate = driverLicenseIssueDate;
}

@PrePersist
public void prePersist(){
System.out.println("DriverLicense Entity :: Method PrePersist Invoked Upon Entity "+this);
}

}

[/code]

The Result is

[code lang=”java”]

PersistenceContextListener :: Method PrePersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@74b957ea
PersistenceContextListener :: Method PrePersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Address@edc86eb
Address Entity :: Method PrePersist Invoked Upon Entity net.javabeat.eclipselink.data.Address@edc86eb
PersistenceContextListener :: Method PrePersist Invoked Upon Entity :: net.javabeat.eclipselink.data.DriverLicense@6f7918f0
DriverLicense Entity :: Method PrePersist Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@6f7918f0
PersistenceContextListener :: Method PostPersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Address@edc86eb
PersistenceContextListener :: Method PostPersist Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@74b957ea
PersistenceContextListener :: Method PostPersist Invoked Upon Entity :: net.javabeat.eclipselink.data.DriverLicense@6f7918f0
PersistenceContextListener :: Method PreUpdate Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@74b957ea
PersistenceContextListener :: Method PostUpdate Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@74b957ea
PersistenceContextListener :: Method PreRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.DriverLicense@6f7918f0
License Entity :: Method PreRemove Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@6f7918f0
PersistenceContextListener :: Method PreRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@74b957ea
PersistenceContextListener :: Method PreRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Address@edc86eb
PersistenceContextListener :: Method PostRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.DriverLicense@6f7918f0
License Entity :: Method PostRemove Invoked Upon Entity net.javabeat.eclipselink.data.DriverLicense@6f7918f0
PersistenceContextListener :: Method PostRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Employee@74b957ea
PersistenceContextListener :: Method PostRemove Invoked Upon Entity :: net.javabeat.eclipselink.data.Address@edc86eb

[/code]

• If you’ve tried to override a method without mentioning the same method name and the same callback type, you’re probably about getting a new method that will not be count a callback method override.

Summary

The Entity callback lifecycle methods is one of the important subject when you are trying to go deep in the JPA. This tutorial provide you the required definition and counts for the callback methods that could help you debugging and traversing the different operations of JPA.

If you’ve a good experience in the Java Persistence API, you can configure the JPA to generates the required schema. These are not part of the JPA implementation prior to the JPA 2.1 specification. These are considered as the extensions for the JPA provider. However, this has been standardized from the JPA 2.1 release. JPA 2.1 added a series of properties for database schema maintenance and generation. This tutorial explains how to use the EclipseLink for generating schema for the database tables.

EclipseLink provides you a eclipselink.dll- generation to specify how EclipseLink generates the DDL (Data Defintion Language) for the database schema (tables and constraints) on deployment.

EclipseLink DDL Valid Values

The property of eclipselink.ddl- generation has multiple valid values and these are:

• create-tables: EclipseLink will attempt to execute a CREATE TABLE SQL for each table. If the table already exists, EclipseLink will follow the default behavior for your specific database and JDBC driver combination (When a CREATE TABLE SQL is issued for an already existing table). In most cases an exception is thrown and the table is not created; the existing table will be used. EclipseLink will then continue with the next statement.
• create-or-extend-tables: EclipseLink will attempt to create tables. If the table exists, EclipseLink will add any missing columns.
• drop-and-create-tables: EclipseLink will attempt to DROP all tables, then CREATE all tables. If any issues are encountered. EclipseLink will follow the default behavior for your specific database and specific JDBC driver combination, then continue with the next statement. This is useful in development if the schema frequently changes or during testing when an existing data needs to be cleared.
• none: default, no ddl generated; no schema generated.

Generated EclipseLink Tutorial Schema

The examples that created for serving the EclipseLink Tutorial were depends on database schema that created before. The entities that are created now contains a different relationships and properties ranging from primary keys (Simple and composite) and associations (including OneTOne, OneToMany, ManyToOne and ManyToMany) to inheritance and identities generation. But what could happen if we are going to use the EclipseLink DDL generation; is it enough for creating identical schema for that manually created schema. Let’s see.

Figure 1.0 shows you the manually created schema contains the existing associations and properties for its tables.

Figure 1.0

• The model described the associations from a database perspective.

Figure 1.1 shows you the schema that’s created by using the EclipseLink -ddl-generation.

Figure 1.1

• The JavaBeat schema that shown at the Figure 1.1 displays the generated schema by using EclipseLink-ddl-generation.
• The model describe the schema from an Object-Oriented perspective.

The Required Persistence Configuration

[code lang=”xml”]

<properties>
<property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/JavaBeat-jpa-generate"/>
<property name="javax.persistence.jdbc.user" value="root"/>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="javax.persistence.jdbc.password" value="root"/>
<property name="eclipselink.logging.level" value="FINEST"/>
<property name="eclipselink.ddl-generation" value="create-tables"/>
</properties>

[/code]

• The property eclipselink.ddl-generation will be used to configure the strategy that would be used for create the schema.

Export the Generated DDL Into External File

You’ve a choice to export the generated schema into external DDL, you’ve to add a new property into your persistence configuration.

[code lang=”xml”]

<properties>
<property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/JavaBeat-jpa-generate"/>
<property name="javax.persistence.jdbc.user" value="root"/>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="javax.persistence.jdbc.password" value="root"/>
<property name="eclipselink.logging.level" value="FINEST"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="sql-script"/>
</properties>

[/code]

• The eclipselink.ddl-generation.output-mode property has three attributes that could be applied.

1. both: DDL will be generated and written to both the database and a file.
2. database: (Default) DDL will be generated and written to the database only.
3. sql-script: DDL will be generated and written to a file only.

• The ddl file will be generated and given a default name.

Assign a name to the files generated:

If you’ve desired to give a specific name for the generated files, you can use an additional eclipselink properties.

[code lang=”xml”]

<properties>
<property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/JavaBeat-jpa-generate"/>
<property name="javax.persistence.jdbc.user" value="root"/>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="javax.persistence.jdbc.password" value="root"/>
<property name="eclipselink.logging.level" value="FINEST"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="sql-script"/>
<property name="eclipselink.create-ddl-jdbc-file-name" value="sql-create-script"/>
// Created statements file name
<property name="eclipselink.drop-ddl-jdbc-file-name" value="sql-drop-script"/>// Dropped statements file name
</properties>

[/code]

Change the location of the created files:

If you’ve desired to change the location of the generated files, you can use an additional eclipselink property called eclipselink.application-location.

[code lang=”xml”]

<property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/JavaBeat-jpa-generate"/>
<property name="javax.persistence.jdbc.user" value="root"/>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="javax.persistence.jdbc.password" value="root"/>
<property name="eclipselink.logging.level" value="FINEST"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="sql-script"/>
<property name="eclipselink.create-ddl-jdbc-file-name" value="sql-create-script"/>
<property name="eclipselink.drop-ddl-jdbc-file-name" value="sql-drop-script"/>
<property name="eclipselink.application-location" value="c:/javabeat-database-files"/>

[/code]

Figure 1.2 shows you the files created under the specified folder.

Figure 1.3

Deploy-On-Startup

If you’ve desired to generate the DDL schema upon that’s time the entity manager factory acquired not by creation of entity manager instance you have to provide a eclipselink deploy-on-startup property. That property accepting two values true or false, where the true means the DDL generation should started once the factory of entity manager instance has been created, meanwhile the false means the DDL generation should started once the entity manager instance has been created.

[code lang=”xml”]

<property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/JavaBeat-jpa-generate"/>
<property name="javax.persistence.jdbc.user" value="root"/>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="javax.persistence.jdbc.password" value="root"/>
<property name="eclipselink.logging.level" value="FINEST"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="sql-script"/>
<property name="eclipselink.create-ddl-jdbc-file-name" value="sql-create-script"/>
<property name="eclipselink.drop-ddl-jdbc-file-name" value="sql-drop-script"/>
<property name="eclipselink.application-location" value="c:/javabeat-database-files"/>
<property name="eclipselink.deploy-on-startup" value="false"/>

[/code]

• This property is important if you’ve worked in a huge application, in that the database creation might take a while or in case the factory creation take place at the initialization of the application and the entity manager not created yet.

Summary

Eclipselink provides much extension properties that can be stated at the persistence.xml file which can be used to configure the EclipseLink JPA framework. This tutorial mentioned properties that can be used to generate a database schema based on the created objects.

This is not only the properties that could be provided by the eclipse for such that configuration, but also it contains other additional properties might be discussed on later tutorial for handling eclipselink exception, for accessing eclipselink descriptor and mapping API.

At this tutorial we’ve explained the concept of entity identification. Entity identification is the process in which the Java Persistence Implementation identify an entity uniquely from set of entities that belong to the same type on a memory level or a database level. Each entity that located in the persistence context must has a unique identifier called Primary Key.

The primary key must be defined on the entity that is form the root of the entity hierarchy or on mapped superclass of the entity hierarchy. The primary key must be defined once in an entity hierarchy, so if you’ve ever tried to create an entity without mentioning of its primary key (Entity Identifier), you are always getting a compiler error as you would be seeing in the following fragment  below.

This fragment of code was extracted from a previous code that made before for Employee Entity (See EclipseLink Tutorial Examples). The identifier is only defined inside Employee entity; Employee is the root of the entity hierarchy that contains a Developer, ContractorDeveloper and FreelanceDeveloper as a sub-classes (entities).

A simple (i.e non-composite) primary key must correspond to a single entity persistent field or property of the entity class. The @Id annotation is used to denote a simple primary key. A composite primary key must correspond to a either a single persistent field or property or to a set of fields or properties.

The primary key (or field or property of a composite primary key) should be one of the following types:

• Java primitive types
• Java primitive wrapper types
• java.lang.String
• java.util.Date (note that the Temporal Type should be specified as DATE)
• java.sql.Date

No rules for simple primary key and few rules applied to composite primary key. The following are the rules applied to the composite primary key:

• The primary key class must be public and must have no-arg constructor.
• The primary key class must be serializable
• The primary key class must define the equals and hashCode methods.
• The composite primary key must either be represented and mapped as embeddable class or must be represented and mapped to multiple fields or properties of the entity class as you would be seeing in this tutorial.
• If the composite primary key class is mapped to multiple fields or properties of the entity class, the names of primary key field or properties in the primary class and those of the entity class must correspond and their types must be the same.
• If the property-access based is used, the properties of the primary key class must be public or protected.

@Id

The Id annotation specifies the primary key property or field of an entity. The Id annotation may be applied in an entity or mapped superclass. See the following fragment of code that shows you the Project entity. Project entity is the root of the entity inheritance.

Project.java

[code lang=”java”]
package net.javabeat.eclipselink.data;

import java.util.List;

import javax.persistence.CascadeType;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
import javax.persistence.ManyToMany;

@Entity(name="Project")
@Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
public abstract class Project {
@Id
private int projectId;

private String projectName;

@ManyToMany(mappedBy="projects",cascade=CascadeType.ALL)
private List employees;

public int getProjectId() {
return projectId;
}

public void setProjectId(int projectId) {
this.projectId = projectId;
}

public String getProjectName() {
return projectName;
}

public void setProjectName(String projectName) {
this.projectName = projectName;
}

public List getEmployees() {
return employees;
}

public void setEmployees(List employees) {
this.employees = employees;
}
}
[/code]

• The Project entity defines the entity identifier, so no need for defining it again the sub-classes that inherit from it.

Let’s see a GlobalProject entity that inherit the Project.

GlobalProject.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import java.math.BigDecimal;

import javax.persistence.Entity;

@Entity
public class GlobalProject extends Project {
private String projectCountry;
private BigDecimal projectBudget;
public String getProjectCountry() {
return projectCountry;
}
public void setProjectCountry(String projectCountry) {
this.projectCountry = projectCountry;
}
public BigDecimal getProjectBudget() {
return projectBudget;
}
public void setProjectBudget(BigDecimal projectBudget) {
this.projectBudget = projectBudget;
}
}

[/code]

• No entity identifier has been defined, cause it’s already defined in the Project.

Anatomy of @Id

• Target: Field or Methods
• Uses: @Id
• Argument: No argument provided

[code lang=”java”]

@Target({METHOD, FIELD}) @Retention(RUNTIME)

public @interface Id {}

[/code]

@IdClass

The IdClass annotation is applied to an entity class or mapped superclass to specify a composite primary key class that’s mapped to multiple fields or properties of the entity.The names of primary key field or properties in the primary class and those of the entity class must correspond and their types must be the same. The Id annotation must also be applied to the corresponding fields or properties of the entity. The next coming lines will show you how to use the IdClass annotation.

Anatomy of @IdClass

• Target: Type
• Uses: @IdClass
• Argument: value that’s must be a class instance

[code lang=”java”]

@Target({TYPE}) @Retention(RUNTIME)

public @interface IdClass {
Class value;
}

[/code]

Database Phone Table

Figure 1.0 shows you the changes that happened at the Phone Table.

Figure 1.0

As you’ve noted in the Figure 1.0, the Phone entity now uses a composite primary key. Let’s see the primary key class.

Implementation of PhonePK

PhonePK.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import java.io.Serializable;

import javax.persistence.IdClass;

// IdClass annotation used  for composite primary key creation

@IdClass(PhonePK.class)

public class PhonePK implements Serializable{
private String phoneCountryKeyId;
private int phoneId;
public String getPhoneCountryKeyId() {
return phoneCountryKeyId;
}
public void setPhoneCountryKeyId(String phoneCountryKeyId) {
this.phoneCountryKeyId = phoneCountryKeyId;
}
public int getPhoneId() {
return phoneId;
}
public void setPhoneId(int phoneId) {
this.phoneId = phoneId;
}
// The override of equals, see the rules mentioned above for creating a composite primary key
public boolean equals(Object obj){
if(obj instanceof PhonePK){
PhonePK phonePK = (PhonePK)obj;
if(this.phoneId == phonePK.getPhoneId() && this.phoneCountryKeyId.equals(phonePK.getPhoneCountryKeyId())){
return true;
}
}
else {
return false;
}
return false;
}
// The override of hashCode, see the rules mentioned above for creating a composite primary key
public int hashCode(){
return super.hashCode();
}

}

[/code]

Implementation of Phone Entity

Phone.java

[code lang=”java”]

package net.javabeat.eclipselink.data;

import javax.persistence.CascadeType;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.IdClass;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;

@Entity(name="Phones")
// If you’ve removed the @IdClass, you’ve got a compiler error
@IdClass(PhonePK.class)
public class Phone {
// By defining two @Id, the JPA assumes that you’ve defined a composite primary key
/* The properties defined inside the Phone entity and annotated with the @Id have the same name and type
of those properties defined in the PhonePK primary key
*/
@Id private int phoneId;
@Id private String phoneCountryKeyId;
private String phoneNumber;

@ManyToOne(cascade=CascadeType.ALL)
@JoinColumn(name="employeeId")
private Employee employee;

public int getPhoneId() {
return phoneId;
}
public void setPhoneId(int phoneId) {
this.phoneId = phoneId;
}
public String getPhoneNumber() {
return phoneNumber;
}
public void setPhoneNumber(String phoneNumber) {
this.phoneNumber = phoneNumber;
}
public Employee getEmployee() {
return employee;
}
public void setEmployee(Employee employee) {
this.employee = employee;
}
public String getPhoneCountryKeyId() {
return phoneCountryKeyId;
}
public void setPhoneCountryKeyId(String phoneCountryKeyId) {
this.phoneCountryKeyId = phoneCountryKeyId;
}

}

[/code]

Executable Application

[code lang=”java”]

package net.javabeat.eclipselink;

import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

import net.javabeat.eclipselink.data.Address;
import net.javabeat.eclipselink.data.AddressPK;
import net.javabeat.eclipselink.data.ContractDeveloper;
import net.javabeat.eclipselink.data.Developer;
import net.javabeat.eclipselink.data.DriverLicense;
import net.javabeat.eclipselink.data.Employee;
import net.javabeat.eclipselink.data.EmployeePeriod;
import net.javabeat.eclipselink.data.FreelanceDeveloper;
import net.javabeat.eclipselink.data.GlobalProject;
import net.javabeat.eclipselink.data.ICDLComputerLicense;
import net.javabeat.eclipselink.data.LocalProject;
import net.javabeat.eclipselink.data.Phone;
import net.javabeat.eclipselink.data.PhonePK;
import net.javabeat.eclipselink.data.Project;

public class JPAImpl {
static EntityManagerFactory factory = null;
static EntityManager em = null;
static {
factory = Persistence.createEntityManagerFactory("EclipseLink-JPA-Installation");
em = factory.createEntityManager();
}

public static void main(String [] args){

// Begin a Transaction
em.getTransaction().begin();
createEmployee();
// Commit
em.getTransaction().commit();
// Inquiry about Phone Using the PhonePK
inquiryUsingPhonePK();

}

public static void createEmployee(){
// Create an address entity
Address address = new Address();

// Address Embeddable class (Type) instantiation
AddressPK addressPK = new AddressPK();
addressPK.setAddressId(1);
addressPK.setAddressCountryId(1);
// addressPK.setAddressCityId(1);
address.setAddressId(addressPK);
address.setAddressCountry("United Kingdom");
address.setAddressCity("London");
// Create an employee entity
Employee employee = new Employee();
employee.setEmployeeId(2);
employee.setEmployeeName("John Smith");

// Create an Employee Period Instance
EmployeePeriod period = new EmployeePeriod();
period.setStartDate(new Date());
period.setEndDate(new Date());

employee.setEmployeePeriod(period);

// Associate the address with the employee
employee.setAddress(address);
// Create a Phone entity
Phone firstPhone = new Phone();
// PhoneId and PhoneCountryKeyId is now the primary key for the phone entity
firstPhone.setPhoneId(3);
firstPhone.setPhoneCountryKeyId("+441");
firstPhone.setPhoneNumber("4050 615");
firstPhone.setEmployee(employee);
// Create a list of phone
List phones = new ArrayList();
phones.add(firstPhone);

// Create a list of projects
List projects = new ArrayList();

// Set the project into employee
employee.setProjects(projects);
// Set the phones into your employee
employee.setPhones(phones);

// Persist the employee

em.persist(employee);
}

public static void inquiryUsingPhonePK(){
PhonePK pk = new PhonePK();
pk.setPhoneId(3);
pk.setPhoneCountryKeyId("+441");
Object obj = em.find(Phone.class, pk);
if(obj instanceof Phone){
Phone phone = (Phone)obj;
System.out.println(phone.getPhoneId());
System.out.println(phone.getPhoneCountryKeyId());
System.out.println(phone.getPhoneNumber());
}
System.out.println(obj);
}

}

[/code]

• The Phone entity has a composite primary key
• The phone entity has been created successfully with its new primary key
• The PhonePK primary key used later for inquiring the Phone persisted instance.

@EmbeddedId

The @EmbeddedId is the second way that already used before for creating a primary key. See @Embeddable, Embeeded and @EmbeddedId example.

Summary

Java Persistence API provides you a various kind of primary keys. Primary key used to identify the entity that’s being persisted either in the memory or inside the database. @Id used to define a simple primary key, while the @IdClass and @EmbeddedId for composite.