openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: [jira] Updated: (OPENJPA-370) LoadFetchGroup annotation was not recognized during the fetch1
Date Mon, 17 Sep 2007 17:47:48 GMT
> during the parsing phase. If we restrict that if Field f specifies
> LoadFetchGroup L then L must be declared in the scope of the same
> parsing unit, then capturing that 'indirect' information becomes
> plausible.

It could be that we do it the way it's done currently to allow
subclasses to contribute to the LoadFetchGroup.

-Patrick

On 9/17/07, Pinaki Poddar <ppoddar@bea.com> wrote:
> I am guessing the reason is in the way our data structures
> (FieldMetaData and FetchConfiguration) capture the information.
> They are designed to answer the 'direct' question:
>     FetchConfiguration.hasField(String fullyQualifiedFieldName)
> and FieldMetaData.isInFetchGroup(String fg).
>
>  But with LoadFetchGroup the answer is 'indirect' -- should field f be
> included because of someone else?
> To answer that question efficiently and in a localized manner -- I think
> we need to capture more info into FieldMetaData
> during the parsing phase. If we restrict that if Field f specifies
> LoadFetchGroup L then L must be declared in the scope of the same
> parsing unit, then capturing that 'indirect' information becomes
> plausible.
>
>  As the question could not be answered in a localized manner with
> current data structures -- the approach was to check if everything is
> loaded before being returned to the caller. And if not, then add the
> LoadFetchGroups temporarily for loading.
>
>
> Pinaki Poddar
> 972.834.2865
>
>
> >-----Original Message-----
> >From: Patrick Linskey [mailto:plinskey@gmail.com]
> >Sent: Monday, September 17, 2007 12:22 PM
> >To: dev@openjpa.apache.org
> >Subject: Re: [jira] Updated: (OPENJPA-370) LoadFetchGroup
> >annotation was not recognized during the fetch1
> >
> >> Also if a field f is included in current FectConfiguration
> >can then be
> >> decided uniformly in one place i.e.
> >> FecthConfigurationImpl.includes(FieldMetaData fmd);
> >
> >Generally-speaking, that sounds like a good goal. I'm not sure
> >if there is a reason why the fetch group handling is done
> >differently during the StateManagerImpl.loadField() call, but
> >all things being equal, it would be good to reduce the
> >different ways that fetch groups are configured where possible.
> >
> >-Patrick
> >
> >On 9/17/07, Pinaki Poddar <ppoddar@bea.com> 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:jira@apache.org]
> >> >Sent: Friday, September 14, 2007 2:19 PM
> >> >To: dev@openjpa.apache.org
> >> >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.ja
> >> >va
> >> >===================================================================
> >> >---
> >> >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.
> >>
> >
> >
> >--
> >Patrick Linskey
> >202 669 5907
> >
>
> 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.
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message