|<< Back to previous view|
[JPA_SPEC-26] Add fetch profile support for queries Created: 24/May/12 Updated: 18/Jan/13 Resolved: 18/Jan/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|File Attachments:||FetchProfile.java FetchUtil.java FetchUtilTest.java|
|Tags:||jpa query jpql|
|Participants:||c.beikov and ldemichiel|
The spec currently does not provide a possibillity to add additional join fetches for an existing query.
could also be written as,
and be transformed by providing the property paths at runtime.
I suggest to add the following method:
A basic query could then be transformed at runtime to fit the needs of the requester of objects.
A basic service method that returns a list of objects could be extended to provide the option of passing the property paths as parameters like:
If you have two views for example, that would like to use that service, but one view needs an additional relation to be fetched, you would have to copy the method with all of the code and fetch the needed relation within the copied method. The suggested approach of using property paths for fetching relations would reduce the total number of queries and methods needed in an application.
Additionally a more type safe approach could be provided by using the static metamodel, but I did not thought through that one. I am not sure if deep paths, like relation.anotherRelation.yetAnotherRelation could be represented when using static metamodel, but at least with strings it is possible.
Hibernate already has a simmilar feature, but it is not as flexible as this approach would be(also see http://docs.jboss.org/hibernate/orm/3.5/reference/en/html/performance.html#performance-fetching-profiles).
|Comment by c.beikov [ 24/May/12 09:08 PM ]|
I added a really simple strategy that places an identifier in a base query and replaces it by the actual fetch code. A test for that approach is also provided.
|Comment by ldemichiel [ 18/Jan/13 12:45 AM ]|
This is now addressed by the entity group functionality. Entity groups can specify fetch plans for queries.