Pinaki, Yes, I realized that the loadField in the StateManagerImpl has all I needed. But I found out that this method was never called in my test.. So I simulated the logic in my patch.. I also looked at the includes method in the FetchConfigurationImpl too.. I will look at it again to see the reason why I can't put the code in one place.. Teresa
On 9/17/07, Pinaki Poddar <[EMAIL PROTECTED]> wrote: > > > Hi, > 1. Within the load sequence, the LoadFetchGroup is handled in > org.apache.openjpa.kernel.StateManagerImpl > > protected void loadField(int, int, boolean, boolean); > > This method checks for any associated LoadFetchGroup L for a field f, > adds L to the current FetchConfiguration temporarily and removes L after > load. This codepath is not getting executed withh your test case -- I > have not debugged it to find out why. > > 2. This method follows a similar approach as in your approach i.e. add > L temporarily and then remove it. > > 3. The other line of attck will be to capture enough information > during annotation metadata parsing so that > FecthConfigurationImpl method > private boolean includes(FieldMetaData fmd); > can affirm if fmd is included in the currrent FetchConfiguration if not > directly (as it does now) > then indirectly via LoadFetchGroup. > In this way, we can get rid of both temporarily-add-and-then-remove and > check-during-StateManagerImpl.loadField() approach. > Also if a field f is included in current FectConfiguration can then be > decided uniformly in one place i.e. > FecthConfigurationImpl.includes(FieldMetaData fmd); > > > > > Pinaki Poddar > 972.834.2865 > > > >-----Original Message----- > >From: Teresa Kan (JIRA) [mailto:[EMAIL PROTECTED] > >Sent: Friday, September 14, 2007 2:19 PM > >To: [email protected] > >Subject: [jira] Updated: (OPENJPA-370) LoadFetchGroup > >annotation was not recognized during the fetch1 > > > > > > [ > >https://issues.apache.org/jira/browse/OPENJPA-370?page=com.atla > >ssian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > > >Teresa Kan updated OPENJPA-370: > >------------------------------- > > > > Attachment: TestFetchGroup.zip > > > >Attach the patch. See the following changes: > >Index: > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/Delegati > >ngFetchConfiguration.java > >=================================================================== > >--- > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/Delegati > >ngFetchConfiguration.java (revision 574344) > >+++ > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/Delegati > >ngFetchConfiguration.java (working copy) > >@@ -287,6 +287,9 @@ > > } > > } > > > >+ public void removeLoadFetchGroup(){ > >+ > >+ } > > public Set getFields() { > > try { > > return _fetch.getFields(); > >Index: > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/FetchCon > >figuration.java > >=================================================================== > >--- > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/FetchCon > >figuration.java (revision 574344) > >+++ > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/FetchCon > >figuration.java (working copy) > >@@ -192,7 +192,10 @@ > > public FetchConfiguration clearFetchGroups(); > > > > /** > >- * Resets the set of fetch groups to the list in the > >global configuration. > >+ * Resets the set of fetch groups to the list in the > >global configuration. > >+ * The global configuration will be the default plus any > >fetch groups > >+ * that are added by the openjpa.FetchGroups property in > >the persistence.xml > >+ * file. > > */ > > public FetchConfiguration resetFetchGroups(); > > > >@@ -197,6 +200,11 @@ > > public FetchConfiguration resetFetchGroups(); > > > > /** > >+ * Remove the loadFetchGroup if there is any loadFetchGroup. > >+ */ > >+ public void removeLoadFetchGroup(); > >+ > >+ /** > > * Returns the set of fully-qualified field names that > >this component > > * will use when loading objects. Defaults to the empty > >set. This set is > > * not thread safe. > >Index: > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/FetchCon > >figurationImpl.java > >=================================================================== > >--- > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/FetchCon > >figurationImpl.java (revision 575491) > >+++ > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/FetchCon > >figurationImpl.java (working copy) > >@@ -92,6 +92,7 @@ > > private boolean _load = true; > > private int _availableRecursion; > > private int _availableDepth; > >+ private String _lfg = null; > > > > public FetchConfigurationImpl() { > > this(null); > >@@ -287,7 +288,14 @@ > > getFetchGroupsList())); > > return this; > > } > >+ > >+ public void removeLoadFetchGroup() { > >+ if (_lfg != null) > >+ removeFetchGroup(_lfg); > >+ _lfg = null; > >+ } > > > >+ > > public Set getFields() { > > return (_state.fields == null) ? > >Collections.EMPTY_SET : _state.fields; > > } > >@@ -568,8 +576,16 @@ > > return true; > > String[] fgs = fmd.getCustomFetchGroups(); > > for (int i = 0; i < fgs.length; i++) > >- if (hasFetchGroup(fgs[i])) > >+ if (hasFetchGroup(fgs[i])) { > >+ String fg = fmd.getLoadFetchGroup(); > >+ if (fg != null) { > >+ if (!hasFetchGroup(fg)) { > >+ addFetchGroup(fg); > >+ _lfg = fg; > >+ } > >+ } > > return true; > >+ } > > return false; > > } > > > >@@ -576,7 +592,7 @@ > > /** > > * Return the available recursion depth via the given > >field for the > > * given type. > >- * > >+ * > > * @param traverse whether we're traversing the field > > */ > > private int getAvailableRecursionDepth(FieldMetaData fm, > >Class type, > >Index: > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateMan > >agerImpl.java > >=================================================================== > >--- > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateMan > >agerImpl.java (revision 575494) > >+++ > >openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateMan > >agerImpl.java (working copy) > >@@ -358,6 +358,10 @@ > > // is loaded, etc > > int lockLevel = calculateLockLevel(active, forWrite, fetch); > > boolean ret = loadFields(fields, fetch, lockLevel, > >sdata, forWrite); > >+ // call back to FetchConfiguration to clean up any > >loadFetchGroup. > >+ // The loadFetchGroup was set by the > >FetchConfigurationImpl.includes() > >+ // during the process of the getUnloadedInternal method. > >+ fetch.removeLoadFetchGroup(); > > obtainLocks(active, forWrite, lockLevel, fetch, sdata); > > return ret; > > } > >Index: > >openjpa-kernel/src/main/java/org/apache/openjpa/meta/FieldMetaData.java > >=================================================================== > >--- > >openjpa-kernel/src/main/java/org/apache/openjpa/meta/FieldMetaD > >ata.java (revision 574693) > >+++ > >openjpa-kernel/src/main/java/org/apache/openjpa/meta/FieldMetaD > >ata.java (working copy) > >@@ -710,6 +710,8 @@ > > /** > > * The fetch group that is to be loaded when this > >receiver is loaded, or > > * null if none set. > >+ * The LoadFetchGroup does not relate to the FetchGroup > >annotation. Therefore > >+ * resets a fetch group will not remove this LoadFetchGroup. > > */ > > public void setLoadFetchGroup (String lfg) { > > if ("".equals(lfg)) > > > > > >> LoadFetchGroup annotation was not recognized during the fetch1 > >> -------------------------------------------------------------- > >> > >> Key: OPENJPA-370 > >> URL: > >https://issues.apache.org/jira/browse/OPENJPA-370 > >> Project: OpenJPA > >> Issue Type: Bug > >> Components: kernel > >> Affects Versions: 1.1.0 > >> Reporter: Teresa Kan > >> Attachments: TestFetchGroup.zip > >> > >> > >> 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. >
