openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste BRIAUD -- Novlog <>
Subject Re: Fetch plan question
Date Mon, 07 Dec 2009 10:13:18 GMT

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
>> 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
> 408 276-5638
> P.S. A good JDO? O, Gasp!

View raw message