[
https://issues.apache.org/jira/browse/OPENJPA-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106272#comment-18106272
]
ASF subversion and git services commented on OPENJPA-2985:
----------------------------------------------------------
Commit c52b5f053c35fc3e8876f16f5dd8def7b8bd1d4d in openjpa's branch
refs/heads/OPENJPA-2985 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=c52b5f053 ]
[OPENJPA-2985] Implement EntityManager.find(EntityGraph, Object, FindOption...)
find(EntityGraph, Object, FindOption...) threw UnsupportedOperationException.
It now looks up an instance of the root entity type of the given graph
(EntityGraphImpl.getEntityType()) by primary key and applies the graph as a
JPA 3.2 load graph: every attribute named by the graph and, recursively, by
its subgraphs and key subgraphs is added to the fetch plan, while attributes
outside the graph keep their declared fetch behaviour - the default fetch
group is deliberately left in place, which is what distinguishes a load graph
from a fetch graph.
Details:
- The graph is applied to a fetch plan pushed for the duration of the call
only, so neither the entity manager's fetch plan nor its maximum fetch
depth is affected afterwards. The maximum fetch depth is raised only when
the graph is nested deeper than a currently configured finite depth; an
infinite depth (-1) is never lowered.
- Attributes are resolved through ClassMetaData/FieldMetaData and added by
their full name (declaring type + field), so attributes inherited from a
mapped superclass or a superclass entity are matched correctly.
- A subgraph's declared class type is preferred, falling back to the declared
type of the owning value's element/key, because for a plural attribute
EntityGraphImpl derives the subgraph type from Attribute.getJavaType(),
which is the collection type.
- Recursion is bounded by a path scoped identity guard, so a graph that
references itself terminates.
- A null graph, a null primary key, a non-entity root type and a foreign
EntityGraph implementation all raise IllegalArgumentException; the message
for a foreign implementation mirrors
EntityManagerFactoryImpl.addNamedEntityGraph.
- The FindOption parsing of find(Class, Object, FindOption...) was extracted
into a shared private helper so both overloads behave identically. The only
observable delta on the existing overload is that an explicit null option
array is now a no-op instead of an NPE, matching lock(Object, LockModeType,
LockOption...).
Tested by the new TestEntityGraphFind (10 tests) in the existing entitygraph
test package; EGDepartment gained a lazy inverse collection so a graph has
something to change. The tests assert the load state via the state manager's
loaded bit set and pair every positive assertion with a fresh entity manager
control that asserts the attribute is NOT loaded without the graph, covering
a flat graph, a subgraph, a cyclic graph, find options, a missing row and the
three IllegalArgumentException cases.
> 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)
