What is the best way to perform custom result sets using JPA or HQL with Spring? - spring

Question

I develop a little Web Service using Spring REST API. I just wanted to know what is the best way to build a custom data result set from a query using HQL or Criterias.
Let's assume we need to handle these 2 entities to perform the following HQL request:
SELECT m.idMission, m.driver, m.dateMission FROM MissionEntity m
The Mission entity (simplified form):
#Entity
public class Mission
{
Integer idMission; //id of the mission
String dateMission; //date of the mission
[...] //Other fields not needed for my request
#ManyToOne
#JoinColumn(name = "driver",
referencedColumnName = "id_user")
User driver; //the driver (user) associated to the mission
[...] //Accessors
};
And the User entity (the driver) (simplified form):
#Entity
public class User
{
Integer idUser; //id of the user
[...] //Others fields not needed for my request
#OneToMany
List<Mission> missionList; //the missions associated to the user
[...] //Accessors
};
JSON output (first result):
[
[ //Mission: depth = 0 (root)
1,
{ //Driver: depth = 1 (mission child -> User)
"idUser": 29,
"shortId": "Adr_Adr",
"lastname": "ADRIAN",
"firstname": null,
"status": "Driver",
"active": 1
},
"05/03/2015"
],
[...]
]
As you can see, I have a custom Mission entity result set (List) which the pattern for each Mission entity is the following:
+ Object
- missionId (Integer)
+ driver (User)
- idUser
- shortId
- lastname
- firstname
- status
- active
- dateMission (String)
But for the purpose of my request I only need for the User entity its firstname and its lastname.
So I need a result set like the following one:
+ Mission (Mission)
- missionId (Integer)
+ driver (User)
- lastname
- firstname
- dateMission (String)
As you can see, I want to keep the same JSON tree structure: a mission entity own a child User entity but this time with a partial set of attributes (only the firstname and the lastname is needed in the set).
For the moment, the only way to solve my problem is to use 2 additionnal POJO classes:
The UserProj class:
public class UserProj
{
private String firstname, lastname;
public UserProj(String firstname, String lastname)
{
this.firstname = firstname;
this.lastname = lastname;
}
[...] //Accessors
};
The MissionProj class:
public class MissionProj
{
private Integer missionId;
private UserProj driver;
private String dateMission;
public MissionProj(Integer missionId,
String driverFirstname, String driverLastname, String dateMission)
{
this.missionId = missionId;
{
this.driver = new UserProj(driverFirstname, driverLastname);
}
this.dateMission = dateMission;
}
[...] //Accessors
};
Here's now the request I use to get the wished JSON output result set:
[
{
"missionId": 1,
"driver": {
"firstname": null,
"lastname": "ADRIAN"
},
"dateMission": "05/03/2015"
},
[...]
]
As you can see, the result set is the one I was looking for! But my problem with that solution is that solution is not scalable. In fact, if I want to perform another custom result set for the User or the Mission entity with one additional field, I will have to create another POJO for this other custom result set. So for me this solution is not really a solution.
I think it should exist a way to do this properly using HQL or Criteria directly but I couldn't find it! Do you have an idea ?
Thanks a lot in advance for your help!

Answer 1

As you can see, the result set is the one I was looking for! But my problem with that solution is that solution is not scalable. In fact, if I want to perform another custom result set for the User or the Mission entity with one additional field, I will have to create another POJO for this other custom result set. So for me this solution is not really a solution.
You are honestly trying to push functionality too low in your architecture which obviously manifests the problem which you describe.
As a bit of background, the SELECT NEW functionality which is exposed by HQL/JPQL and the JPA Criteria was introduced as an easy way to take a query of selectables and inject them into a value object by properly selecting the right constructor method. What the caller does with the constructed value objects is an application concern, not one for the persistence provider.
I believe a more scalable solution would be not to rely on the persistence provider to deal with this but to instead push this back upstream on the Jackson API directly, which is already designed and built to handle this case quite easily.
You'd want Hibernate to return a List<Mission> objects which have the appropriate state from all dependent objects initialized based on your application needs. Then you would either have your service tier or controller transform this list using custom Jackson serializers.
public class MissionSerializer extends StdSerializer<Mission> {
private boolean serializeSpecialField;
public MissionSerializer() {
this( null );
}
public MissionSerializer(Class<Mission> clazz) {
super( clazz );
}
public void setSerializeSpecialField(boolean value) {
this.serializeSpecialField = value;
}
#Override
public void serialize(
Mission value,
JsonGenerator jgen,
SerializerProvider provider)
throws IOException, JsonProcessingException {
// use jgen to write the custom mappings of Mission
// using the serializeSpecialField to control whether
// you serialize that field.
}
}
Then at this point, it's a matter of getting the ObjectMapper and setting the serializer again either in your service tier or controller and toggling whether you serialize the extra field.
The benefit here is that the query remains constant, allowing the persistence provider to cache the entities from the query, improving performance, all while allowing the application tier to transform the results to the final destined output.
This solution does likely imply you may have a single query you have to manage and a single Jackson Serializer to handle this task, so from a technical debt it may be reasonable.
On the other hand, there are good arguments to avoid coupling two solutions for the sake of code reuse.
For example, what if you'd like to change one use case? Now because you reuse the same code, one use case change implies the other is impacted, must be tested, and verified it's still stable and unaffected. By not reusing code, you avoid this potential risk, especially if your test suite doesn't have full coverage.