You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com> on 2009/12/05 12:27:29 UTC
Fetch plan question
Hi,
I'm a big fan of fetch plan but there is something I don't understand.
I have a root class with many link or relation.
I'm using annotation and only annotation. Mose of the link are set with EAGER fetching and cascade ALL.
This is done so by default, fetch will be eager and action will cascade the attributes.
This is the wanted default behavior when no fetch plan is used.
I'm using fetch plan to override that behavior when I need it.
Unfortunately, because most of the time my relation are eagerly fetched by default it may have hidden bad behavior or bug to me.
When I use fetch plan to add some field to retrieve tham, it works but maybe due to the default behavior I have specified in the annotation.
However I had tested to add to fetch plan an attribute that was not eagerly retreived and it had worked when I was discovering the OpenJPA API.
The question come now : how to dynamically, using fetch plan, exclude (rather than adding) to the fetch plan some attribute not to retrieve ?
It is something to override my default definition of fetching in the annotation.
I found the method fetplan.removeField(...) is it the right one to use to exclude an attribute from being processed (whatever it will be updated, read, ...) ?
Can that be mixed in the fetch plan : removeField and addField ?
To speed up the code is there a way to exclude all attributes before adding the few I want to add ?
It would be quicker and simpler than having to remove one by one the field I didn't added.
fetplan.removeAllFields(Class) and the other way around :
fetplan.addAllFields(Class)
Thanks !
Re: Fetch plan question
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
On Dec 7, 2009, at 01:30 , Craig L Russell wrote:
> Hi,
Hi, thanks for your answer,
>
> On Dec 5, 2009, at 3:27 AM, Jean-Baptiste BRIAUD -- Novlog wrote:
>
>> Hi,
>>
>> I'm a big fan of fetch plan but there is something I don't understand.
>> I have a root class with many link or relation.
>> I'm using annotation and only annotation. Mose of the link are set with EAGER fetching and cascade ALL.
>> This is done so by default, fetch will be eager and action will cascade the attributes.
>> This is the wanted default behavior when no fetch plan is used.
>>
>> I'm using fetch plan to override that behavior when I need it.
>> Unfortunately, because most of the time my relation are eagerly fetched by default it may have hidden bad behavior or bug to me.
>> When I use fetch plan to add some field to retrieve tham, it works but maybe due to the default behavior I have specified in the annotation.
>> However I had tested to add to fetch plan an attribute that was not eagerly retreived and it had worked when I was discovering the OpenJPA API.
>>
>> The question come now : how to dynamically, using fetch plan, exclude (rather than adding) to the fetch plan some attribute not to retrieve ?
>
> Can you show some snippet of code where you specify the fetch plan?
Very difficult to make it clear to you since I built a framework to simply to the max the use of fetchPlan.
I'll digg for a bug in my code since your answer confirmed the awaited behavior was correct.
> When you retrieve the current fetch plan all of the defaults are in place so you need to remove them from the fetch plan if you don't want to fetch the fields.
Yes, that was basically the heart of my question and you confirmed I was doing right.
As I don't want to deal with hundreds of line to remove fields one by one (nearly all are set to EAGER in my annotations) I added all fields I don't want to a collection using introspection and I then browse the collection and remove the field from fetchPlan.
Unfortunately, despite the fact I add only the field I want and remove the one I don't want, the result behavior is not correct : either fetchPlan not taken into account or remove don't work the way I did.
I'm investigating the my code, the bug must be there as I had tested fetchPlan before choosing OpenJPA and it worked fine.
>
> If you have fetch groups defined you might need to remove these as well to completely remove the fields from the list of fields fetched.
No, I don't have any fetch group but it sound like ok to remove it if any.
>
>> It is something to override my default definition of fetching in the annotation.
>>
>> I found the method fetplan.removeField(...) is it the right one to use to exclude an attribute from being processed (whatever it will be updated, read, ...) ?
>>
>> Can that be mixed in the fetch plan : removeField and addField ?
>
> Sure.
OK, I feel better as it confirm I understood concept :-)
>>
>> To speed up the code is there a way to exclude all attributes before adding the few I want to add ?
>> It would be quicker and simpler than having to remove one by one the field I didn't added.
>> fetplan.removeAllFields(Class) and the other way around :
>> fetplan.addAllFields(Class)
>
> This sounds like a non-optimization to me. It just isn't that expensive to construct fetch plans.
It depends on the default set via annotation, let me clarify : if nearly all attributes including relation are set to EAGER and if you want for one request only few of them, you'll have hundreds of lines of code to remove all you don't want.
The removeAll would act like "I want nothing", now let me "add only what I want".
I don't feel this would be heavy to add in the OpenJPA code.
>
> Craig
>>
>> Thanks !
Thanks again !
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Fetch plan question
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi,
On Dec 5, 2009, at 3:27 AM, Jean-Baptiste BRIAUD -- Novlog wrote:
> Hi,
>
> I'm a big fan of fetch plan but there is something I don't understand.
> I have a root class with many link or relation.
> I'm using annotation and only annotation. Mose of the link are set
> with EAGER fetching and cascade ALL.
> This is done so by default, fetch will be eager and action will
> cascade the attributes.
> This is the wanted default behavior when no fetch plan is used.
>
> I'm using fetch plan to override that behavior when I need it.
> Unfortunately, because most of the time my relation are eagerly
> fetched by default it may have hidden bad behavior or bug to me.
> When I use fetch plan to add some field to retrieve tham, it works
> but maybe due to the default behavior I have specified in the
> annotation.
> However I had tested to add to fetch plan an attribute that was not
> eagerly retreived and it had worked when I was discovering the
> OpenJPA API.
>
> The question come now : how to dynamically, using fetch plan,
> exclude (rather than adding) to the fetch plan some attribute not to
> retrieve ?
Can you show some snippet of code where you specify the fetch plan?
When you retrieve the current fetch plan all of the defaults are in
place so you need to remove them from the fetch plan if you don't want
to fetch the fields.
If you have fetch groups defined you might need to remove these as
well to completely remove the fields from the list of fields fetched.
> It is something to override my default definition of fetching in the
> annotation.
>
> I found the method fetplan.removeField(...) is it the right one to
> use to exclude an attribute from being processed (whatever it will
> be updated, read, ...) ?
>
> Can that be mixed in the fetch plan : removeField and addField ?
Sure.
>
> To speed up the code is there a way to exclude all attributes before
> adding the few I want to add ?
> It would be quicker and simpler than having to remove one by one the
> field I didn't added.
> fetplan.removeAllFields(Class) and the other way around :
> fetplan.addAllFields(Class)
This sounds like a non-optimization to me. It just isn't that
expensive to construct fetch plans.
Craig
>
> Thanks !
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Re: Fetch plan question
Posted by Miłosz <mt...@o2.pl>.
> I noticed that the queries generated are of the form "where (o.id = 1 or
> o.id = 2 or o.id = 3)" rather than "where o.id in (1, 2, 3)". Any reason for
> this?
Maybe because some databases have (or had) limit on maximum length of the IN (...) list?
Cheers,
Milosz
Re: Fetch plan question
Posted by Daryl Stultz <da...@6degrees.com>.
On Mon, Dec 14, 2009 at 10:31 AM, Pinaki Poddar <pp...@apache.org> wrote:
>
> Hi Daryl,
> Prepared Query Cache is used when a JPQL query is executed *more than
> once*.
Thanks for the explanation. I was under the impression (at least with 1.2.1)
that the query cache cannot be enabled unless data cache is enabled. I did
not enable data cache (and I'm assuming the default for 2.0 is disabled).
The parametrization of the cached SQL is not
> always possible -- especially for IN expression parameters which can vary
> in
> number of parameters on successive executions.
I noticed that the queries generated are of the form "where (o.id = 1 or
o.id = 2 or o.id = 3)" rather than "where o.id in (1, 2, 3)". Any reason for
this?
> So, can you please post the test that failed with
> openjpa.jdbc.QuerySQLCache=true?
> Also mention which version of OpenJPA was used for the test.
>
My current production code is 1.2.1 based. I have to pull things apart a bit
to run it with 2.0M3. I'm too busy right now, but I'll try to squeeze it in
sometime over the next couple of weeks.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Fetch plan question
Posted by Pinaki Poddar <pp...@apache.org>.
Hi Daryl,
Prepared Query Cache is used when a JPQL query is executed *more than
once*. What Prepared Query Cache does is to cache the target SQL query upon
first execution of JPQL and in subsequent invocation of the same JPQL,
executes the SQL without paying the cost of forming the SQL again. This has
significant performance benefits (+50% in some cases). The tricky part of
the problem is to reparametrize the cached SQL on subsequent executions.
The failure as you had seen with that cache being active is related to
that re-parametrization path. The parametrization of the cached SQL is not
always possible -- especially for IN expression parameters which can vary in
number of parameters on successive executions. Ideally we should be able to
detect such limitation during re-parametrization and fall back
*automatically* to execute the original JPQL. Somehow with your test that
did not happen.
So, can you please post the test that failed with
openjpa.jdbc.QuerySQLCache=true?
Also mention which version of OpenJPA was used for the test.
Daryl Stultz wrote:
>
> On Sat, Dec 12, 2009 at 7:44 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
>>
>> Set <property name="openjpa.jdbc.QuerySQLCache", value="false"/>
>>
>> That took care of the secondary problem, so I can now complete the action
> that was originally failing.
>
> Thanks.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
>
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Fetch-plan-question-tp4117231p4164748.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Fetch plan question
Posted by Daryl Stultz <da...@6degrees.com>.
On Sat, Dec 12, 2009 at 7:44 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
> Set <property name="openjpa.jdbc.QuerySQLCache", value="false"/>
>
> That took care of the secondary problem, so I can now complete the action
that was originally failing.
Thanks.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Fetch plan question
Posted by Pinaki Poddar <pp...@apache.org>.
Set <property name="openjpa.jdbc.QuerySQLCache", value="false"/>
Daryl Stultz wrote:
>
> On Fri, Dec 11, 2009 at 5:27 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
>>
>> Please try in a realistic setup if the fix works. I just ran a version of
>> your test to verify the fix.
>>
>> The best that I can tell, the "real application" code that was failing is
> now succeeding. I now have a different crash after the previously failing
> code. I had thought it might have something to do with the classes being
> enhanced for 1.2.1. I believe I have successfully enhanced my classes with
> 2.0M3. I'm getting this error:
>
> org.apache.openjpa.persistence.ArgumentException: The specified parameter
> of
> type "class com.sixdegreessoftware.apps.rss.model.Case" is not a valid
> query
> parameter.
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1436)
> at
> org.apache.openjpa.jdbc.kernel.PreparedSQLStoreQuery$PreparedSQLExecutor.executeQuery(PreparedSQLStoreQuery.java:113)
> at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1001)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:859)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:790)
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525)
> at
> org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:288)
> at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:300)
>
> from my code that looks like this:
>
> *private* *void* loadScheduledAssignments(List<Case> caseList) {
>
> Query query = ExecutionResources.*getEntityManager*().createQuery("select
> o
> from ScheduledAssignment as o" +
>
> " join fetch o.caze" +
>
> " left join fetch o.brokenRuleLookup" +
>
> " where o.caze in (:cases)" +
>
> " order by o.role.printOrder, o.user.lastName, o.user.firstName,
> o.user.middleInitial");
>
> query.setParameter("cases", caseList);
>
> List<ScheduledAssignment> resultList = query.getResultList();
>
>
> caseList is populated with 2 cases and runs fine the first time through.
> The
> second time it fails (with one case in list) and fails all subsequent
> times
> (with the original 2 cases). If this is completely unrelated to your fix,
> then I guess I'm good, but I'd like to perform the previously failing
> operation without running into another snag before saying the fix was
> successful. I'm tired of battling with it for now.
>
> The fix (or the error) has nothing to do with FetchPlan -- it is some
> other
>> internal optimization that caused the AOOB exception.
>>
>> So is there no hope for avoiding it in 1.2.1?
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
>
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Fetch-plan-question-tp4117231p4158093.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Fetch plan question
Posted by Daryl Stultz <da...@6degrees.com>.
On Fri, Dec 11, 2009 at 5:27 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
> Please try in a realistic setup if the fix works. I just ran a version of
> your test to verify the fix.
>
> The best that I can tell, the "real application" code that was failing is
now succeeding. I now have a different crash after the previously failing
code. I had thought it might have something to do with the classes being
enhanced for 1.2.1. I believe I have successfully enhanced my classes with
2.0M3. I'm getting this error:
org.apache.openjpa.persistence.ArgumentException: The specified parameter of
type "class com.sixdegreessoftware.apps.rss.model.Case" is not a valid query
parameter.
at
org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1436)
at
org.apache.openjpa.jdbc.kernel.PreparedSQLStoreQuery$PreparedSQLExecutor.executeQuery(PreparedSQLStoreQuery.java:113)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1001)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:859)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:790)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525)
at
org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:288)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:300)
from my code that looks like this:
*private* *void* loadScheduledAssignments(List<Case> caseList) {
Query query = ExecutionResources.*getEntityManager*().createQuery("select o
from ScheduledAssignment as o" +
" join fetch o.caze" +
" left join fetch o.brokenRuleLookup" +
" where o.caze in (:cases)" +
" order by o.role.printOrder, o.user.lastName, o.user.firstName,
o.user.middleInitial");
query.setParameter("cases", caseList);
List<ScheduledAssignment> resultList = query.getResultList();
caseList is populated with 2 cases and runs fine the first time through. The
second time it fails (with one case in list) and fails all subsequent times
(with the original 2 cases). If this is completely unrelated to your fix,
then I guess I'm good, but I'd like to perform the previously failing
operation without running into another snag before saying the fix was
successful. I'm tired of battling with it for now.
The fix (or the error) has nothing to do with FetchPlan -- it is some other
> internal optimization that caused the AOOB exception.
>
> So is there no hope for avoiding it in 1.2.1?
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Fetch plan question
Posted by Pinaki Poddar <pp...@apache.org>.
Please try in a realistic setup if the fix works. I just ran a version of
your test to verify the fix.
The fix (or the error) has nothing to do with FetchPlan -- it is some other
internal optimization that caused the AOOB exception.
Daryl Stultz wrote:
>
> On Fri, Dec 11, 2009 at 3:31 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
>>
>> Hi Daryl,
>> The change is committed on trunk at revision 889799.
>> Can you try to see if it resolves the problem?
>>
>> I got the latest as of this afternoon, a few past 889799. I've tested
> against my isolated unit test and it's good. I'll try it in my full
> application when I get a chance.
>
> I've pulled back from using fetch plan completely until this is resolved.
> Can you give me some idea of the problem, perhaps I can use fetch plan
> selectively knowing what the arrangement is that yields the error?
>
> Thanks for the quick attention!
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
>
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Fetch-plan-question-tp4117231p4154130.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Fetch plan question
Posted by Daryl Stultz <da...@6degrees.com>.
On Fri, Dec 11, 2009 at 3:31 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
> Hi Daryl,
> The change is committed on trunk at revision 889799.
> Can you try to see if it resolves the problem?
>
> I got the latest as of this afternoon, a few past 889799. I've tested
against my isolated unit test and it's good. I'll try it in my full
application when I get a chance.
I've pulled back from using fetch plan completely until this is resolved.
Can you give me some idea of the problem, perhaps I can use fetch plan
selectively knowing what the arrangement is that yields the error?
Thanks for the quick attention!
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Fetch plan question
Posted by Pinaki Poddar <pp...@apache.org>.
Hi Daryl,
The change is committed on trunk at revision 889799.
Can you try to see if it resolves the problem?
Daryl Stultz wrote:
>
> On Thu, Dec 10, 2009 at 12:51 PM, Pinaki Poddar <pp...@apache.org>
> wrote:
>
>>
>> Hi Daryl,
>> > I posted a unit test on 11/18 here but didn't draw any interest.
>>
>> I can not find the unit test. Please let me know where it is exactly.
>> Is there a JIRA for it? If not, please create -- whatever it is, an AOBE
>> is
>> a bug.
>>
>
> https://issues.apache.org/jira/browse/OPENJPA-1424
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
>
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Fetch-plan-question-tp4117231p4153596.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Fetch plan question
Posted by Daryl Stultz <da...@6degrees.com>.
On Thu, Dec 10, 2009 at 12:51 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
> Hi Daryl,
> > I posted a unit test on 11/18 here but didn't draw any interest.
>
> I can not find the unit test. Please let me know where it is exactly.
> Is there a JIRA for it? If not, please create -- whatever it is, an AOBE is
> a bug.
>
https://issues.apache.org/jira/browse/OPENJPA-1424
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Fetch plan question
Posted by Pinaki Poddar <pp...@apache.org>.
Hi Daryl,
> I posted a unit test on 11/18 here but didn't draw any interest.
I can not find the unit test. Please let me know where it is exactly.
Is there a JIRA for it? If not, please create -- whatever it is, an AOBE is
a bug.
Daryl Stultz wrote:
>
> On Wed, Dec 9, 2009 at 10:40 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
>>
>> > Wow, that fetchPlan API is just far more powerful than I thought.
>>
>> That is good to know :)
>>
>
> Pinaki, I had been using fetch plan for a while until I ran into a nasty,
> unexplainable error.
>
> java.lang.ArrayIndexOutOfBoundsException: 2
> at
> org.apache.openjpa.meta.ClassMetaData.getExtraFieldDataIndex(ClassMetaData.java:859)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:358)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
>
> I had to abandon its usage (reverting to a single level left join fetch in
> my queries). I posted a unit test on 11/18 here but didn't draw any
> interest. I can't say for sure it's a bug in OpenJPA, but you see the
> stack
> trace. It's not a super simple test case, but perhaps you can take a look
> at
> it and give me some tips for isolating the problem.
>
> Thanks.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
>
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Fetch-plan-question-tp4117231p4146760.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Fetch plan question
Posted by Daryl Stultz <da...@6degrees.com>.
On Wed, Dec 9, 2009 at 10:40 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
> > Wow, that fetchPlan API is just far more powerful than I thought.
>
> That is good to know :)
>
Pinaki, I had been using fetch plan for a while until I ran into a nasty,
unexplainable error.
java.lang.ArrayIndexOutOfBoundsException: 2
at
org.apache.openjpa.meta.ClassMetaData.getExtraFieldDataIndex(ClassMetaData.java:859)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:358)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
I had to abandon its usage (reverting to a single level left join fetch in
my queries). I posted a unit test on 11/18 here but didn't draw any
interest. I can't say for sure it's a bug in OpenJPA, but you see the stack
trace. It's not a super simple test case, but perhaps you can take a look at
it and give me some tips for isolating the problem.
Thanks.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Fetch plan question
Posted by Pinaki Poddar <pp...@apache.org>.
> Wow, that fetchPlan API is just far more powerful than I thought.
That is good to know :)
Jean-Baptiste BRIAUD -- Novlog wrote:
>
> HI Craig,
>
> Wow, that fetchPlan API is just far more powerful than I thought. I'll
> have to dig that, I'm sure our OpenJPA layer need improvements :-)
>
> OpenJPA really rocks !
>
> On Dec 7, 2009, at 22:59 , Craig L Russell wrote:
>
>>
>> On Dec 7, 2009, at 1:44 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
>>
>>> How do you do that ?
>>>
>>> I'm using a new EM for one client-server network request but even in one
>>> client-server network request there may be several database request, so
>>> I would be interested to know how to you set a fetch plan for one
>>> request only.
>>
>> There is a fetch plan for the em that can be modified. Subsequent
>> operations use the modified fetch plan.
>>
>> There is a fetch plan for a query that is initialized to the fetch plan
>> for the em at the time you create the query. The fetch plan for the query
>> can be modified and it only affects that query.
>>
>> If you want to modify the fetch plan for a series of queries and then
>> revert the fetch plan, take a look at OpenJPAEntityManager.pushFetchPlan
>> and popFetchPlan.
>>
>> Craig
>>>
>>> On Dec 7, 2009, at 22:13 , Daryl Stultz wrote:
>>>
>>>> On Mon, Dec 7, 2009 at 3:48 PM, Jean-Baptiste BRIAUD -- Novlog <
>>>> j-b.briaud@novlog.com> wrote:
>>>>
>>>>> Now, thanks to you, I'm doing the following :
>>>>> final FetchPlan fetchPlan = entityManager.getFetchPlan();
>>>>> fetchPlan.clearFetchGroups();
>>>>> fetchPlan.clearFields();
>>>>> fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>>>>>
>>>>>
>>>> FWIW, if you don't know already, modifying the fetch plan at the EM
>>>> level
>>>> affects all subsequent queries. You can also modify the fetch plan for
>>>> individual queries.
>>>>
>>>> --
>>>> Daryl Stultz
>>>> _____________________________________
>>>> 6 Degrees Software and Consulting, Inc.
>>>> http://www.6degrees.com
>>>> mailto:daryl@6degrees.com
>>>
>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
>
>
-----
Pinaki
--
View this message in context: http://n2.nabble.com/Fetch-plan-question-tp4117231p4143547.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Fetch plan question
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
HI Craig,
Wow, that fetchPlan API is just far more powerful than I thought. I'll have to dig that, I'm sure our OpenJPA layer need improvements :-)
OpenJPA really rocks !
On Dec 7, 2009, at 22:59 , Craig L Russell wrote:
>
> On Dec 7, 2009, at 1:44 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
>
>> How do you do that ?
>>
>> I'm using a new EM for one client-server network request but even in one client-server network request there may be several database request, so I would be interested to know how to you set a fetch plan for one request only.
>
> There is a fetch plan for the em that can be modified. Subsequent operations use the modified fetch plan.
>
> There is a fetch plan for a query that is initialized to the fetch plan for the em at the time you create the query. The fetch plan for the query can be modified and it only affects that query.
>
> If you want to modify the fetch plan for a series of queries and then revert the fetch plan, take a look at OpenJPAEntityManager.pushFetchPlan and popFetchPlan.
>
> Craig
>>
>> On Dec 7, 2009, at 22:13 , Daryl Stultz wrote:
>>
>>> On Mon, Dec 7, 2009 at 3:48 PM, Jean-Baptiste BRIAUD -- Novlog <
>>> j-b.briaud@novlog.com> wrote:
>>>
>>>> Now, thanks to you, I'm doing the following :
>>>> final FetchPlan fetchPlan = entityManager.getFetchPlan();
>>>> fetchPlan.clearFetchGroups();
>>>> fetchPlan.clearFields();
>>>> fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>>>>
>>>>
>>> FWIW, if you don't know already, modifying the fetch plan at the EM level
>>> affects all subsequent queries. You can also modify the fetch plan for
>>> individual queries.
>>>
>>> --
>>> Daryl Stultz
>>> _____________________________________
>>> 6 Degrees Software and Consulting, Inc.
>>> http://www.6degrees.com
>>> mailto:daryl@6degrees.com
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Fetch plan question
Posted by Craig L Russell <Cr...@Sun.COM>.
On Dec 7, 2009, at 1:44 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
> How do you do that ?
>
> I'm using a new EM for one client-server network request but even in
> one client-server network request there may be several database
> request, so I would be interested to know how to you set a fetch
> plan for one request only.
There is a fetch plan for the em that can be modified. Subsequent
operations use the modified fetch plan.
There is a fetch plan for a query that is initialized to the fetch
plan for the em at the time you create the query. The fetch plan for
the query can be modified and it only affects that query.
If you want to modify the fetch plan for a series of queries and then
revert the fetch plan, take a look at
OpenJPAEntityManager.pushFetchPlan and popFetchPlan.
Craig
>
> On Dec 7, 2009, at 22:13 , Daryl Stultz wrote:
>
>> On Mon, Dec 7, 2009 at 3:48 PM, Jean-Baptiste BRIAUD -- Novlog <
>> j-b.briaud@novlog.com> wrote:
>>
>>> Now, thanks to you, I'm doing the following :
>>> final FetchPlan fetchPlan = entityManager.getFetchPlan();
>>> fetchPlan.clearFetchGroups();
>>> fetchPlan.clearFields();
>>> fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>>>
>>>
>> FWIW, if you don't know already, modifying the fetch plan at the EM
>> level
>> affects all subsequent queries. You can also modify the fetch plan
>> for
>> individual queries.
>>
>> --
>> Daryl Stultz
>> _____________________________________
>> 6 Degrees Software and Consulting, Inc.
>> http://www.6degrees.com
>> mailto:daryl@6degrees.com
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Fetch plan question
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
How do you do that ?
I'm using a new EM for one client-server network request but even in one client-server network request there may be several database request, so I would be interested to know how to you set a fetch plan for one request only.
On Dec 7, 2009, at 22:13 , Daryl Stultz wrote:
> On Mon, Dec 7, 2009 at 3:48 PM, Jean-Baptiste BRIAUD -- Novlog <
> j-b.briaud@novlog.com> wrote:
>
>> Now, thanks to you, I'm doing the following :
>> final FetchPlan fetchPlan = entityManager.getFetchPlan();
>> fetchPlan.clearFetchGroups();
>> fetchPlan.clearFields();
>> fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>>
>>
> FWIW, if you don't know already, modifying the fetch plan at the EM level
> affects all subsequent queries. You can also modify the fetch plan for
> individual queries.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
RE: Fetch plan question
Posted by Michael Vorburger <mv...@odyssey-group.com>.
https://issues.apache.org/jira/browse/OPENJPA-1416
Re: Fetch plan question
Posted by Daryl Stultz <da...@6degrees.com>.
On Mon, Dec 7, 2009 at 3:48 PM, Jean-Baptiste BRIAUD -- Novlog <
j-b.briaud@novlog.com> wrote:
> Now, thanks to you, I'm doing the following :
> final FetchPlan fetchPlan = entityManager.getFetchPlan();
> fetchPlan.clearFetchGroups();
> fetchPlan.clearFields();
> fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>
>
FWIW, if you don't know already, modifying the fetch plan at the EM level
affects all subsequent queries. You can also modify the fetch plan for
individual queries.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Fetch plan question
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
On Dec 7, 2009, at 18:57 , Michael Vorburger wrote:
> Jean-Baptiste,
Hi Michael,
>
> I realized that in our own in-house "framework to simply to the max the
> use of fetchPlan" (just like yours... and ours?) we must be doing the
> same
we may share some ideas or some directions ...
> , so I refereshed my memories by looking back at that code for you
Thanks !
> (written over a year ago) and suddenly remembered that indeed there is a
> little "trick", you have to:
>
> fp.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>
It was that, a big big thanks.
I'm still wondering why the API do not provide a removeAllGroups and removeALLFields, so even without knowing the name of any groups or fields, the fetch plan would be 100% empty.
I thought that it was already done by that code :
final FetchPlan fetchPlan = entityManager.getFetchPlan();
fetchPlan.clearFetchGroups();
fetchPlan.clearFields();
Now, thanks to you, I'm doing the following :
final FetchPlan fetchPlan = entityManager.getFetchPlan();
fetchPlan.clearFetchGroups();
fetchPlan.clearFields();
fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);
> Because (quote from doc) "any field that is eagerly loaded according to
> the JPA metadata rules into the built-in default fetch group. As its
> name implies, the default fetch group is active by default. You may also
> define your own..."
>
In fact, you right, I read that but I still thought I didn't have fetchGroup forgetting the default one.
> Does this help? If yes, why don't you create a little Defect suggest
> that the documentation be slightly slightly improved to take this
> crystal clear? Once you know it I guess the phrase above is clear, but
> if you don't, it's probably not clear enough?
Exactly that !
> A few lines of example & explanation may have helped you?
Yes definitively, I would have notices the extra fetchPlan.removeFetchGroup(FetchGroup.NAME_DEFAULT);
>
>
>> Magazine mag = em.find(Magazine.class, magId);
>> Will it work also with a query and not only with the find(id) method ?
>> Something like that : em.createQuery("SELECT blablabla ..."); ??
>
> Yes yes of course. Make sure you also read & understand the
> http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/
> ref_guide_perfpack_eager.html stuff though.
>
OK, this was like others recents question a way to confirm what I try to do is correct. When something goes wrong, I always suspect my own understanding first.
> Ciao.
>
Thanks a lot, I could spent days without finding that default fetchgroup thing.
RE: Fetch plan question
Posted by Michael Vorburger <mv...@odyssey-group.com>.
Jean-Baptiste,
I realized that in our own in-house "framework to simply to the max the
use of fetchPlan" (just like yours... and ours?) we must be doing the
same, so I refereshed my memories by looking back at that code for you
(written over a year ago) and suddenly remembered that indeed there is a
little "trick", you have to:
fp.removeFetchGroup(FetchGroup.NAME_DEFAULT);
Because (quote from doc) "any field that is eagerly loaded according to
the JPA metadata rules into the built-in default fetch group. As its
name implies, the default fetch group is active by default. You may also
define your own..."
Does this help? If yes, why don't you create a little Defect suggest
that the documentation be slightly slightly improved to take this
crystal clear? Once you know it I guess the phrase above is clear, but
if you don't, it's probably not clear enough? A few lines of example &
explanation may have helped you?
> Magazine mag = em.find(Magazine.class, magId);
> Will it work also with a query and not only with the find(id) method ?
> Something like that : em.createQuery("SELECT blablabla ..."); ??
Yes yes of course. Make sure you also read & understand the
http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/
ref_guide_perfpack_eager.html stuff though.
Ciao.
Re: Fetch plan question
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
In fact, when I call, for debugging purpose, the fetchPlan.getFields() methods, I can check that the field I need and only the fields I need are there.
=> the fetchPlan itself is correct.
Then, what should I do to "use" the fetchplan ? I can't find my old test that was pure OpenJPA (without all my application code I have now) but I remember I can use entityManager just as simply as without fetchplan.
The fact to create and set a fetchplan from that entityManager is enough to tell the entityManager to "use" it.
Am i right ?
Also, here in the doc : http://openjpa.apache.org/builds/1.0.2/apache-openjpa-1.0.2/docs/manual/ref_guide_fetch.html
I read that example :
OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
kem.getFetchPlan().addField(Magazine.class, "publisher");
Magazine mag = em.find(Magazine.class, magId);
Will it work also with a query and not only with the find(id) method ?
Something like that : em.createQuery("SELECT blablabla ..."); ??
On Dec 7, 2009, at 15:20 , Jean-Baptiste BRIAUD -- Novlog wrote:
> I call this 2 methods before adding the fields I want but still it doesn't behave like expected.
>
> On Dec 7, 2009, at 13:00 , Michael Vorburger wrote:
>
>>> how to dynamically, using fetch plan, exclude (rather than adding) to
>> the fetch plan some attribute not to retrieve
>>
>> I probably misunderstand, but doesn't FetchPlan.clearFields() +
>> FetchPlan.clearFetchGroups() followed by a few addField() do what you
>> want (I haven't tried) ?
>>
>> http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/javadoc
>> /org/apache/openjpa/persistence/FetchPlan.html
>>
>
>
Re: Fetch plan question
Posted by Jean-Baptiste BRIAUD -- Novlog <j-...@novlog.com>.
I call this 2 methods before adding the fields I want but still it doesn't behave like expected.
On Dec 7, 2009, at 13:00 , Michael Vorburger wrote:
>> how to dynamically, using fetch plan, exclude (rather than adding) to
> the fetch plan some attribute not to retrieve
>
> I probably misunderstand, but doesn't FetchPlan.clearFields() +
> FetchPlan.clearFetchGroups() followed by a few addField() do what you
> want (I haven't tried) ?
>
> http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/javadoc
> /org/apache/openjpa/persistence/FetchPlan.html
>
RE: Fetch plan question
Posted by Michael Vorburger <mv...@odyssey-group.com>.
> how to dynamically, using fetch plan, exclude (rather than adding) to
the fetch plan some attribute not to retrieve
I probably misunderstand, but doesn't FetchPlan.clearFields() +
FetchPlan.clearFetchGroups() followed by a few addField() do what you
want (I haven't tried) ?
http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/javadoc
/org/apache/openjpa/persistence/FetchPlan.html