[
https://issues.apache.org/jira/browse/OPENJPA-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106271#comment-18106271
]
ASF subversion and git services commented on OPENJPA-2985:
----------------------------------------------------------
Commit 7c8df6d949d939d5c7a8a3cecb0bcf947c859448 in openjpa's branch
refs/heads/OPENJPA-2985 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=7c8df6d94 ]
[OPENJPA-2985] Implement EntityManagerFactory.getNamedQueries(Class)
EntityManagerFactoryImpl.getNamedQueries(Class) no longer throws
UnsupportedOperationException. It now forces loading of the persistent
types (mirroring the private MetaDataRepository.resolveAll() that
getQueryMetaData() uses, so a cold repository does not yield an empty
result), iterates the query metadata and returns a freshly built map of
TypedQueryReference for every named query whose declared result type is
assignable to the requested type. The declared result type is
QueryMetaData.getResultType(), falling back to getCandidateType(), which
makes the predicate exactly "createNamedQuery(name, resultType) is
legal". Named queries without any declared result type are never
returned, for any type including Object.class. The returned map is a
copy; each reference carries the query name, the result type and an
unmodifiable copy of the query hints. A null result type is rejected
with IllegalArgumentException and a closed factory raises the usual
IllegalStateException.
For this to be answerable from metadata,
AnnotationPersistenceMetaDataParser.parseNamedQueries() now honours the
JPA 3.2 @NamedQuery.resultClass() the same way parseNamedNativeQueries()
already honours @NamedNativeQuery.resultClass(): a managed result class
is stored as the candidate type, any other non-void class as the result
type. This is the identical branch that QueryImpl.setResultClass()
performs for createNamedQuery(name, resultClass), so behaviour matches
an explicit result class at the call site; note that setting the
candidate type also makes JPQLExpressionBuilder skip its own candidate
inference, which is the same situation as today's
createNamedQuery(name, X.class).
XMLPersistenceMetaDataParser is deliberately untouched: the bundled
orm_3_2.xsd.rsrc declares only a "name" attribute on <named-query>, so a
"result-class" attribute would fail schema validation before reaching
the parser. Refreshing the schema is left to a separate issue; until
then XML-declared named queries have no declared result type and are
therefore not returned by getNamedQueries().
New TypedQueryReferenceImpl is an immutable TypedQueryReference with
equals/hashCode/toString.
Tested by the new TestGetNamedQueries (with NamedQueryRefEntity, which
declares named queries with an entity resultClass plus a hint, a scalar
resultClass, no resultClass, and a native query with a resultClass):
covers the parser change, entity/scalar/supertype lookups, exclusion of
untyped queries, hints and their immutability, the returned map being a
copy, null argument handling, a cold second factory, addNamedQuery(), and
round-tripping a reference through EntityManager.createQuery().
> Mandatory JPA 3.2 methods throw UnsupportedOperationException
> -------------------------------------------------------------
>
> Key: OPENJPA-2985
> URL: https://issues.apache.org/jira/browse/OPENJPA-2985
> Project: OpenJPA
> Issue Type: Sub-task
> Reporter: Maxim Solodovnik
> Priority: Major
>
> Discussion thread:
> https://github.com/apache/openjpa/pull/144#discussion_r3683005795
> **(low)** `getNamedQueries(Class)` still throws
> UnsupportedOperationException, as do
> `EntityManagerImpl.createQuery(TypedQueryReference)`
> (EntityManagerImpl.java:2779) and `find(EntityGraph, Object, FindOption...)`
> (EntityManagerImpl.java:2645). These are mandatory JPA 3.2 API - planned
> before merge, or tracked in a follow-up JIRA? Worth referencing the issue in
> the exception message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
