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
andWidget
would have a one-to-one relationship. One-to-one relationships use thejavax.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 withLineItem
. One-to-many relationships use thejavax.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 toOrder
is many-to-one. Many-to-one relationships use thejavax.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
andStudent
would have a many-to-many relationship. Many-to-many relationships use thejavax.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 theSELECT
clause.
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, becauseteams
is a collection-valued relationship field. To reach thesport
field, theFROM
clause could define an identification variable namedt
for theteams
field:
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!