Gavin King (
https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929...
) *updated* an issue
Hibernate ORM (
https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiOThlODEwMmE1...
) / New Feature (
https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiOThlOD...
) HHH-14051 (
https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiOThlOD...
) typesafe references to named queries, result set mappings, and entity graphs (
https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiOThlOD...
)
Change By: Gavin King (
https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929...
)
Currently, named queries, entity graphs, and SQL result set mappings are identified by
stringly-typed keys.
It would be better if the metamodel generator would generate a typesafe element that
identifies each of these things defined within a certain persistence unit. The reference
can in principle even encode the result type of the query.
Thus, you would be able to write:
{{ TypedQuery<Book> q = book
session.createNamedQuery(NamedQueries_.bookWithAuthor); }}
Or:
{{ TypedQuery<Book> q = book session.createNativeQuery(sqlQuery,
ResultSetMappings_.bookWithAuthor); }}
Or:
{{ Book book = session.find(Book.class, EntityGraphs_.bookWithAuthor); }}
Or whatever, and have that all be completely typesafe.
Now, a challenge for this is how to determine the "return type" for each sort of
thing.
- * For `@SqlResultSetMapping` and `@NamedNativeQuery`, it's explicit in the
annotation.
- * For `@NamedEntityGraph`, it could reasonably be inferred from the entity class on
which the annotation occurs.
- * For `@NamedQuery` we have a problem.
Now, the query-validator project shows how it's in-principle possible to typecheck a
named JPA query at compile time, however, that approach is currently limited to Java 8.
There do seem to be some clever ways to infer the result type of a `@NamedQuery` in
specific cases, without typechecking the entire query. For example:
- * If there's more than one element in the `select`, it's totally trivial (must
be `Object \ []`).
- * If there's no `select` clause at all, the problem is also pretty easy: either
you've got a `from` with no `join`, in which case the thing after `from` is the name
of the entity, or you have a `from` and a `join`, in which case you're back to `Object
\ []`.
However, for the specific case of exactly one element in the `select` clause, we have a
problem.
So one option would be to add a result type member to the Hibernate `@NamedQuery`
annotation, so that the user can specify it explicitly (defaulting to `Object`, of
course).
Ultimately this would be a great feature to contribute back to the JPA spec.
(
https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey...
) Add Comment (
https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey...
)
Get Jira notifications on your phone! Download the Jira Cloud app for Android (
https://play.google.com/store/apps/details?id=com.atlassian.android.jira....
) or iOS (
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em...
) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100127- sha1:2c97aec )