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:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
