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.
The Java world is evolving at a rapid pace and it can be challenging to keep track of it. Fortunately lots of great resources are created every week, explaining new features or looking at existing stuff from a different angle.
I am using the Java Weekly series to collect the most interesting links I found during the last week and present them to you all in one place. I hope you find it useful and that it makes it easier for you to keep up-to-date. If you like to suggest a resource or something I can improve on, please leave me a comment.
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.
The Java world is evolving at a rapid pace and it can be challenging to keep track of it. Fortunately lots of great resources are created every week, explaining new features or looking at existing stuff from a different angle.
I am using the Java Weekly series to collect the most interesting links I found during the last week and present them to you all in one place. I hope you find it useful and that it makes it easier for you to keep up-to-date. If you like to suggest a resource or something I can improve on, please leave me a comment.
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.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:
The Java world is evolving at a rapid pace and it can be challenging to keep track of it. Fortunately lots of great resources are created every week, explaining new features or looking at existing stuff from a different angle.
I am using the Java Weekly series to collect the most interesting links I found during the last week and present them to you all in one place. I hope you find it useful and that it makes it easier for you to keep up-to-date. If you like to suggest a resource or something I can improve on, please leave me a comment.
Normally, I am using the Java Weekly series to collect the most interesting Java related links. But today I prepared a special April Fool Edition for you. I hope you enjoy it.
.png)
.png)
