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.

Craig

On Oct 23, 2009, at 8:21 AM, 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...

Fay




----- Original Message ----
From: calin014 <[email protected]>
To: [email protected]
Sent: Fri, October 23, 2009 2:13:56 AM
Subject: Re: Fetchgroups recursion problem


Thanks for the quick reply.

I tried that but with no luck.
I did something like this before executing the query:

OpenJPAEntityManager ojem = OpenJPAPersistence.cast(entityManager);
System.out.println("getMaxFetchDepth() before: " +
ojem.getFetchPlan().getMaxFetchDepth());
ojem.getFetchPlan().setMaxFetchDepth(15);
System.out.println("getMaxFetchDepth() after: " +
ojem.getFetchPlan().getMaxFetchDepth());
ojem.getFetchPlan().addFetchGroups("State_OutgoingTransitions",
"IncomingTransitions");

The output is:

getMaxFetchDepth() before: -1
getMaxFetchDepth() after: 15

The result is the same as described in the first post.

Am i doing it wrong?


Pinaki Poddar wrote:

Hi,
There are two attributes that control the closure of a graph as fetched by
a FetchPlan/FetchConfiguration, namely
  Recursion Depth
  Max Fetch Depth

According to the cited use case, Max Fetch Depth is the relevant attribute that will control depth of traversal from a root entity (s1). By default, the max fetch depth is set to 1 and hence the immediate neighbors of s1
are fetched and not s4 or s5 which is at depth 2 from s1.

Recursion depth, on the other hand, controls the depth of traversal for recursive relation on types. If s1 had a recursive relation then recursion
depth would have controlled traversal of that relation path.



--
View this message in context: 
http://n2.nabble.com/Fetchgroups-recursion-problem-tp3874382p3877617.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.





Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[email protected]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to