This apparently has something to do with the _availableRecursion in the FetchConfigurationImpl. I hardcoded a big number and the whole thing is retrieved. There seem a missing link between the recursionDepth in the FetchGroup and this field. More investigation is underway...
Fay ----- Original Message ---- From: calin014 <[email protected]> To: [email protected] Sent: Fri, October 23, 2009 10:37:46 AM Subject: Re: Fetchgroups recursion problem Craig L Russell wrote: > > One other thing to consider: there is a fetch plan for each query that > may be different from the fetch plan for other operations. If you're > modifying the fetch plan after the query is created, the modifications > won't affect the query. > Well, the order is: OpenJPAEntityManager ojem = OpenJPAPersistence.cast(entityManager); ojem.getFetchPlan().setMaxFetchDepth(15); ojem.getFetchPlan().addFetchGroups("State_OutgoingTransitions", "State_IncomingTransitions"); Flow flow = entityManager.find(Flow.class, id); And the query is affected because, if i don't add the fetch groups, only the first state gets loaded into memory. Fay Wang wrote: > > By default, the max fetch depth is set to -1 for no limit. However, this > graph is an "indirect recursion", i.e., from State -> Transition -> State. > I think this makes Openjpa to stop prematurely... > If this is the case, is there a workaround? -- View this message in context: http://n2.nabble.com/Fetchgroups-recursion-problem-tp3874382p3880166.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
