openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Teresa Kan" <>
Subject Re: FetchGroup and FetchAttribute question
Date Fri, 31 Aug 2007 16:46:12 GMT
In addition to previous question, I have question about the lifecycle of a
FetchGroup and need some clarifications on the expected behavior. Please
verify each step result is  a correct behavior. If they are correct, then we
need to document those behavior in the javadoc and openjpa manual:

Use the following example,

   @FetchGroup(name="AddressFetchGroup", attributes=
{@FetchAttribute(name="address")} ),
   @FetchGroup(name="RatingFetchGroup", attributes=
@FetchGroup(name="ManagerFetchGroup1A", attributes= {@FetchAttribute(name=
"manager" , recursionDepth=1)} )
public class FGEmployee{
    private int id;

    private FGAddress address;

    private String rating;

    private FGManager manager;


Test case:
1.         oem.persist(employee);
==> What happen to 3 fetchGroups? Are they active at this time?
>From the debugger, the fetchGroup was set to "default". At this time, I
can't tell whether the default means those 3 fetchGroups or the default w/o
any custom FetchGroups? If I did not reset the FetchGroup and  did not
explicitly add the fetchGroups, both address and rating are eagerly loaded.
So it implies that all 3 fetchGroup are active when the employee is
==> What happen if there is no LoadFetchGroup annotated on rating? Will the
AddressFetchGroup be active ?
>From the test result, this is true.. Then why we need to use LoadFetchGroup

2.          oem.getFetchPlan().resetFetchGroups();
==> What is the expected behavior in resetFetchGroups()? According to the
Resets the set of fetch groups to the list in the global configuration.
What does the "global configuration" mean? The default fetch group w/o
custom fetch group? or the one that defined thru annotation? or the one in
the persistence.xml file?

I assume that 3 fetchGroups are not active. From the debugger, it showed the
"default" which I guessed the default w/o custom fetch groups..
How about the LoadFetchGroup? it seems to me that this fetch group was
deactive too. Is this an expected behavior?
>From the test result, both address and rating are NOT  eargly loaded.

3.             oem.getFetchPlan().addFetchGroups("RatingFetchGroup");
==>  What is the expected behavior? The RatingFetchGroup is added to the
fetchPlan. From the debugger, I saw both default and RatingFetchGroup.
The test result showed the rating was eagerly loaded but not the address. It
seems to me that the resetFetchGroup() disable the AddressFetchGroup even
though it was specified in the rating thru LoadFetchGroup.  Is this an
expected behavior?

4.            FGEmployee emp = oem.find(FGEmployee.class, 1);
==> What happen to the Address and Rating fields?
  a) if Rating does not have the LoadFetchGroup annotation, and no
resetFetchGroup call:
  ===> both Address and Rating are eagerly loaded.
 b) if Rating has the LoadFetchGroup annotation and no resetFetchGroup call:
 ===> same as a)
 c) Regardless of  the LoadFetchGroup, if resetFetchGroup is called and  no
addFetchGroup is called:
 ==> both Address and Rating are not eagerly loaded.
 d) If resetFetchGroup is called and addFetchGroup on RatingFetchGroup is
 ==> Address is LAZY and rating is eager.
 e) if resetFetchGropu is called and addFetchGroup on both Address and
Rating fetch groups:
 ==> both Address and Rating are eagerly loaded.

5) one more question, if I defined a FetchGroup within a FetchGroup, for
                attributes= {
                    @FetchAttribute(name="manager", recursionDepth=1)
                } ),
fetchGroups={"AggregateEmployeeFetchGroup1"} ),
===> if I reset the fetch group, and only add the
AggregateEmployeeFetchGroup2. Nothing will happen because the
AggregateEmployeeFetchGroup1 is deactivated by resetFetchGroup(). Unless I
add both fetchGroup in runtime, none of the dept, address, manager are
eagerly loaded. Is this an expected behavior?

Please verify the above behaviors.. I can't tell the lifecycle of the
FetchGroup that associated with LoadFetchGroup and resetFetchGroup..


On 8/30/07, Teresa Kan <> wrote:
> If I have a fetchAttribute manager which is included in multiple
> FetchGroups. For example,
> @FetchGroup(name="ManagerFetchGroup1A",
> attributes= {
> @FetchAttribute(name="manager" , recursionDepth=1)} ),
> @FetchGroup(name="ManagerFetchGroup1B",
> attributes= {
> @FetchAttribute(name="manager" , recursionDepth=-1)} ),
> @FetchGroup(name="ManagerFetchGroup2",
> attributes= {
> @FetchAttribute(name="manager" , recursionDepth=2)} ),
> In my test case, I did the following:
> oem.getFetchPlan().resetFetchGroups();  ===> reset to default
> oem.clear();
> oem.getFetchPlan().addFetchGroups(
> "ManagerFetchGroup1A");
> I found out that openjpa will add all 3 FetchGroups back to the fetch
> plan. My guess was that the manager was associated with 3 FetchGroups. The
> recursionDepth will be set to -1. Is this an expected behavior? I can't find
> any statement from the openjpa manual. Please clarifiy!
> Thanks,
> Teresa

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message