Projection is a subset of entities' properties. It can be represented as dedicated class (or classes), and mapped either as the database view based entity, or using constructor expressions [1][2]. The clue of this solution is having very limited entities tree (or no tree at all, as in my example) comparing to original entity (Employee). We need to display employee name, thus we build the projection having employee name and ID only. As you will see below, using projections leads to single SQL query, instead of bunch of SQL queries (see example in JPA - Should I become a laziness extremist?)
Database view based entities
What we need in this case is simple JPA entity, mapped to any database view (or table if desired properties are in one table).
Now we can run JPQL query:
select employee from ViewBasedEmployeeNameProjection employee order by employee.name
which in turn will execute one single SQL query:
select EMPLOYEE_ID, EMPLOYEE_NAME from EMPLOYEE order by EMPLOYEE_NAME
Using this method you have to remember that you can choose anything for the projection ID, as long as it uniquely identifies each projection.
Constructor expressions
What we need in this case is a class representing the projection with constructor having parameters corresponding to all properties in the projection.
Now we can run JPQL query:
select new com.blogspot.vardlokkur.domain.EmployeeNameProjection(employee.employeeId, employee.name) from Employee employee order by employee.name
which in turn will execute one single SQL query:
select EMPLOYEE_ID, EMPLOYEE_NAME from EMPLOYEE order by EMPLOYEE_NAME
This method has some disadvantages:
- adding new projection properties increases number of constructor parameters
- projection class name is included in JPQL query, which may lead to refactoring problems
To be continued ...
Few links for the dessert
Follow-ups:
This article has been republished on Dzone's Javalobby (05/06/2013).
No comments:
Post a Comment