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.
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,
Widgetwould have a one-to-one relationship. One-to-one relationships use the
javax.persistence.OneToOneannotation 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,
Orderwould have a one-to-many relationship with
LineItem. One-to-many relationships use the
javax.persistence.OneToManyannotation 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
LineItemthe relationship to
Orderis many-to-one. Many-to-one relationships use the
javax.persistence.ManyToOneannotation 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,
Studentwould have a many-to-many relationship. Many-to-many relationships use the
javax.persistence.ManyToManyannotation 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.
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!
Query Language: The FETCH JOIN.
This is one of those features that just made me say “Suuuuuweet!”. It looks like this:
FETCH JOINis 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
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.
Query Language: Navigation
You’re BLOWING MY MIND here Query Language!
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.sportis illegal, because
teamsis a collection-valued relationship field. To reach the
FROMclause could define an identification variable named
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 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!