openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar" <>
Subject RE: [jira] Commented: (OPENJPA-370) LoadFetchGroup annotation was not recognized during the fetch1
Date Thu, 01 Nov 2007 01:19:54 GMT
The implementation is ensuring that the user instance is loaded with
requisite fields that can be specified by 
A) fetch configuration  
B) fields that are directly accessed  
C) fields that are included because they are member of a
load-fetch-group of another field which is being fetched/accessed.  

For concreteness, let us consider the following

public class PObject {
	private long id;	
	private Integer f2;
	private Integer f3;
	private Integer f4;
	private Integer f5;

Where FetchGroup "f4f5" consists of (you guessed it right:) {"f4",

Consider f3 being accessed either by direct load such as Pobject.getF3()
or activating a FetchGroup {"f3"}.
The resultant PObject instance with f1,f2 unloaded and f3,f4,f5 loaded.
However, this will result in two separate SQL being issued.
SELECT, t0.f3 FROM pobject t0
SELECT t0.f4, t0.f5 FROM pobject t0 WHERE = ?

The first SQL is resulted because f3 is included in current fecth
configuration while f4 and f5 are not. 
The second SQL is resulted of StateManagerImpl.load() that detects f3
has a fetch group "f4f5". It is part of the current fecth session and
not a result of post-fetch analysis. However the way it is done is by
adding "f4f5" to the active fetch configuration temporarily and going
through similar cycle that caused the first SQL.

The concern is I am observing via few test cases this mechanics working
to fulfill the user contract. However, Teresa/Kevin reported/observed
that LoadFetchGroup is not working. Further investigation on this
failure is required before introducing alternative solution.

Regards --

Pinaki Poddar

>-----Original Message-----
>From: Craig Russell (JIRA) [] 
>Sent: Wednesday, October 31, 2007 6:52 PM
>Subject: [jira] Commented: (OPENJPA-370) LoadFetchGroup 
>annotation was not recognized during the fetch1
>    [ 
>_12539221 ] 
>Craig Russell commented on OPENJPA-370:
>> Before the instance is returned to the caller, the fields 
>are checked again if they cause any other field be loaded 
>because LoadFecthGroup. At that point, if field f has a 
>LoadFetchGroup L and L is not part of the active fetch 
>configuration then *temporarily* add L to the active 
>FetchConfiguration and go for another 'fetch' (i.e. from the 
>This sounds wrong. The effect of the load fetch group should 
>be part of the fetch strategy, and no post-fetch analysis 
>should be done. The only time the load fetch group is used is 
>if a field f is accessed and it's not already fetched. 
>The intent of the load fetch group is to augment the fetch 
>plan under which the persistent instance was fetched. It's 
>designed to provide an intelligent fetch strategy for the 
>lower-usage cases where some use needs field f1 (not in any 
>fetch group in the current fetch plan) and when using field f1 
>you want to also fetch fields f2, f3, and f4, that are also 
>not part of the current fetch plan.
>> LoadFetchGroup annotation was not recognized during the fetch1
>> --------------------------------------------------------------
>>                 Key: OPENJPA-370
>>                 URL: 
>>             Project: OpenJPA
>>          Issue Type: Bug
>>          Components: kernel
>>    Affects Versions: 1.0.1, 1.1.0
>>            Reporter: Teresa Kan
>>            Assignee: Teresa Kan
>>             Fix For: 1.0.1, 1.1.0
>>         Attachments: OPENJPA_370_2.patch,
>> Employee class has a LoadFetchGroup annotation defined on 
>the Rating field, when getRating was called, the address 
>should be returned also. However, openjpa did not handle the 
>LoadFetchGroup correctly, therefore, address was not eargly fetched.
>> 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;
>> ..
>> }
>This message is automatically generated by JIRA.
>You can reply to this email to add a comment to the issue online.

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