I’m preparing for a presentation on JPA fundamentals for my team, so I’m reading Introduction to the Java Persistence API from Sun’s Java EE tutorial. I’d like to record some of my thoughts as I’m reading for later reference.

Thought #1

I was concerned about how JPA handles complex data models from the database (one-to-many, many-to-many). Having managed this myself in applications, I know how tricky it can be. I felt very comforted by this segment of the reading

Multiplicity in Entity Relationships

There are four types of multiplicities: one-to-one, one-to-many, many-to-one, and many-to-many.

One-to-one: Each entity instance is related to a single instance of another entity. For example, to model a physical warehouse in which each storage bin contains a single widget, StorageBin and Widget would have a one-to-one relationship. One-to-one relationships use the javax.persistence.OneToOne annotation on the corresponding persistent property or field.

One-to-many: An entity instance can be related to multiple instances of the other entities. A sales order, for example, can have multiple line items. In the order application, Order would have a one-to-many relationship with LineItem. One-to-many relationships use the javax.persistence.OneToMany annotation on the corresponding persistent property or field.

Many-to-one: Multiple instances of an entity can be related to a single instance of the other entity. This multiplicity is the opposite of a one-to-many relationship. In the example just mentioned, from the perspective of LineItem the relationship to Order is many-to-one. Many-to-one relationships use the javax.persistence.ManyToOne annotation on the corresponding persistent property or field.

Many-to-many: The entity instances can be related to multiple instances of each other. For example, in college each course has many students, and every student may take several courses. Therefore, in an enrollment application, Course and Student would have a many-to-many relationship. Many-to-many relationships use the javax.persistence.ManyToMany annotation on the corresponding persistent property or field.

It goes on to describe some of the fine-grained controls that further define relationships. It’s clear to me, though, that JPA can do the heavy lifting.

Thought #2

Holy Crap! If I’m understanding this correctly, JPA essentially sets up an object-oriented model of the data store as it applies to an application, and abstracts all of the best practices of data manipulation into pure business terms. Ahhhhh…the beauty of Object-Oriented design applied to data persistence. I realize I’m years behind on this little revelation, but better late then never!

Thought #3

Query Language: The FETCH JOIN.

This is one of those features that just made me say “Suuuuuweet!”. It looks like this:

A FETCH JOIN is a join operation that returns associated entities as a side-effect of running the query. In the following example, the query returns a set of departments, and as a side-effect, the associated employees of the departments, even though the employees were not explicitly retrieved by the SELECT clause.

SELECT dFROM Department d LEFT JOIN FETCH d.employeesWHERE d.deptno = 1

The first thing that comes to mind is when you are retrieving a record to populate a form with drop-down fields. Perhaps this is a quick ‘n easy way to get the entities for the drop-downs in one call. We’ll see. Somethings are not always as they seem.

Thought #4

Query Language: Navigation

You’re BLOWING MY MIND here Query Language!

Navigation

A path expression enables the query to navigate to related entities. The terminating elements of an expression determine whether navigation is allowed. If an expression contains a single-valued relationship field, the navigation can continue to an object that is related to the field. However, an expression cannot navigate beyond a persistent field or a collection-valued relationship field. For example, the expression p.teams.league.sport is illegal, because teams is a collection-valued relationship field. To reach the sport field, the FROM clause could define an identification variable named t for the teams field:

FROM Player AS p, IN (p.teams) t WHERE t.league.sport = 'soccer'

Are you seeing what I’m seeing here?!! They are using the ‘league’ field of t (a collection of teams) to get to it’s ‘sport’ field. Essentially, JPQL is an object-oriented query language. And how about using fields in your select to construct a new object?

Constructor Expressions

Constructor expressions allow you to return Java instances that store a query result element instead of an Object[].

The following query creates a CustomerDetail instance per Customer matching the WHERE clause. A CustomerDetail stores the customer name and customer’s country name. So the query returns a List of CustomerDetail instances:

SELECT NEW com.xyz.CustomerDetail(c.name, c.country.name)
FROM customer c
WHERE c.lastname = ‘Coss’ AND c.firstname = ‘Roxane’

What an exciting time for software development!