openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar" <>
Subject RE: FetchGroup and FetchAttribute question
Date Fri, 31 Aug 2007 17:23:54 GMT
  Few comments in-line.... 

  What is the mechanics to cofirm if a field is loaded as a result of a
API call?

  Can you post a test case for us to investigate further?

Pinaki Poddar

>-----Original Message-----
>From: Teresa Kan [] 
>Sent: Friday, August 31, 2007 11:46 AM
>To: dev
>Subject: Re: FetchGroup and FetchAttribute question
>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{
>    @Id
>    private int id;
>    @OneToOne(fetch=FetchType.LAZY)
>    private FGAddress address;
>    @Basic(fetch=FetchType.LAZY)
>    @LoadFetchGroup("AddressFetchGroup")
>    private String rating;
>    @ManyToOne(fetch=FetchType.LAZY)
>    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 persisted.

The custome fetch groups are not active under this configuration.
How are you confirming that "both address and rating are eagerly loaded"
-- looking at the SQL issued, by reflectively looking into the instance?
FetchGroups are not relevant during persist() operation. 
In a clean cache, undet the 'default' configuration, for a find() or
query, rating will be fetched and address will not.

>==> 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 explicitly?

If field a has a LoadFetchGropu X -- it means "if field a is loaded also
load all fields included in fecthgroup X". LoadFetchGroup does not
control which fetch group is active.

>2.          oem.getFetchPlan().resetFetchGroups();
>              oem.clean();
>==> 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?

'global configuration' implies the fetch groups specified in
persistence.xml via 'openjpa.FetchGroups' property.

>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.

LoadFetchGroup does not control which fetch group is active.

>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 example, @FetchGroups({  
>                attributes= {
>                    @FetchAttribute(name="dept"),
>                    @FetchAttribute(name="address"),
>                    @FetchAttribute(name="manager", recursionDepth=1)
>                } ),
> @FetchGroup(name="AggregateEmployeeFetchGroup2",
>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 
>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 
>> 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

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

View raw message