The spec currently does not provide a possibillity to add additional join fetches for an existing query.
Queries that have only one driving table/entity like,
could also be written as,
and be transformed by providing the property paths at runtime.
The property path for this example would be relation.
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).