Result Set Mapping: Constructor Result Mappings

This is the third part of my series about SQL result set mappings:

• Result Set Mapping: The Basics
• Result Set Mapping: Complex Mappings
• Result Set Mapping: Constructor Result Mappings
• Result Set Mapping: Hibernate specific features (coming soon)

In the first post of this series, we had a look at some mapping definition between the query result and one entity. The mapping definitions got more complex in the second part, as we mapped the query result to multiple entities and handled additional columns. 

In this post, we will have a look at the Constructor Result Mappings introduced in JPA 2.1. This feature allows us to call the constructor of a value object with the result of the query, similar to the JPQL constructor expressions. This is often used, if we want to provide a specific view of our domain model to the client.

Result Set Mapping: Complex Mappings

This is the second part of my SQL result set mappings series. We had a look at some basic result type mappings in the first post Result Set Mapping: The Basics. In this one, we will define more complex mappings that can map a query result to multiple entities and handle additional columns that cannot be mapped to a specific entity.

• Result Set Mapping: The Basics
• Result Set Mapping: Complex Mappings
• Result Set Mapping: Constructor Result Mappings (coming soon)
• Result Set Mapping: Hibernate specific features (coming soon)

Result Set Mapping: The Basics

Quite often JPQL is not powerful enough to perform the queries we need in real world projects. In general, this is not an issue because JPA is designed as a leaky abstraction and we can use the full potential of SQL by using native queries or calling stored procedures.
The only downside is, that these queries return a List of Object[] instead of the mapped entities and value objects we are used to work with. Each Object[] contains one record returned by the database. We then need to iterate through the array, cast each Object to its specific type and map them to our domain model. This creates lots of repetitive code and type casts as you can see in the following example.


It would be more comfortable, if we could tell the EntityManager to map the result of the query into entities or value objects as it is the case for JPQL statements. The good news is, JPA provides this functionality. It is called SQL result set mapping and we will have a detailed look at it during this series:

• Result Set Mapping: The Basics
• Result Set Mapping: Complex Mappings
• Result Set Mapping: Constructor Result Mappings (coming soon)
• Result Set Mapping: Hibernate specific features (coming soon)

JPA 2.1 - 12 features every developer should know

If you are a regular reader of this blog, you know that I wrote several articles about features and enhancements introduced with JPA 2.1. One thing that was missing, was a general overview about all the changes. So here it is :-)
The following paragraphs provide a description of the 12 features and enhancements introduced with JPA 2.1. And as a special bonus, I created a cheat sheet with a short description and additional code snippets for each change, which you can download for free.

5 ways to initialize lazy relations and when to use them

Lazy loading of relations between entities is a well established best practice in JPA. Its main goal is to retrieve only the requested entities from the database and load the related entities only if needed. That is a great approach, if we only need the requested entities. But it creates additional work and can be the cause of performance problems, if we also need some of the related entities.

Lets have a look at the different ways to trigger the initialization and their specific advantages and disadvantages.