Eager fetching

Question

I believe eager fetching can greatly benefit from more dynamic method then
predefined fetch groups.
Different queries pull different parts of object graph and only client using
object model knows what's needed for a particular query. Trying to fit
conflicting data needs into one set of fetch group is a challenge. While I
would retain this feature I would like to propose field based eager fetching
control. Which can also be used for Detached objects
Lets say we have PO with POLine collection and each POLine references
Product. If we want to eager fetch POs along with their lines and products
we could say something like
pm.getFetchConfiguration().addPath(com.peacetech.sales.PO.class, "lines");
pm.getFetchConfiguration().addPath(com.peacetech.sales.PO.class,
"lines/product");
or
pm.getFetchConfiguration().addPath(com.peacetech.sales.PO.class, pathList);
of course we would need
pm.getFetchConfiguration().removePath(com.peacetech.sales.PO.class,
"lines/product");
pm.getFetchConfiguration().addPath(com.peacetech.sales.PO.class); //remove
all for given class
This is just a crude example. In real life we should have few classes to
support the idea and main class GraphConfig or something so users can
configure, build and reuse those GraphConfig instances and use them for
various purposes like eager fetching and detaching without conflicts
I think it would be enormous help to uncouple so many conflicting issues
(fetch optimizations, optimistic locking field groups, detached graphs etc)
from one very limited concept of predefined fetch groups

Answer 1

Mark,
I mentioned this possibility in on of my prior posts. It is not exactly what
I want (since it lack interclass relations which let you express hints for
deep graph rather than for a class and its fields) but close.
If you maintain your metadata files by hand it is too much effort but since
almost all my models and metadata are generated I can easily do (and undo)
it for each and every class/field and I will give it a try :-)
Alex
"Marc Prud'hommeaux" <[email protected]> wrote in message
news:[email protected]...
Alex-
Well, you could always simulate dynamic fetch groups by defining a
different custom fetch group for each field (provided your license has
the capability to use custom fetch groups). For simplicity, you could
name each fetch group to be "ClassName.fieldName".
That way, you could do something like this:
KodoQuery kq = (KodoQuery) pm.newQuery (MyClass.class, "someQuery");
kq.getFetchConfiguration ().addFetchGroup ("MyClass.fieldA");
kq.getFetchConfiguration ().addFetchGroup ("MyClass.fieldB");
kq.getFetchConfiguration ().addFetchGroup ("MyClass.fieldC");
kq.getFetchConfiguration ().addFetchGroup ("MyClass.fieldD");
Collection results = (Collection) kq.execute ();
It would them be pretty simple to make a static helper method that will
do thing like includeAllFieldsInFatchGroup() or
includeNoFieldsInFetchGroup().
In article <[email protected]>, Alex Roytman wrote:
David Tinker says multiple fetch group is the solution:
Hi Alex
You can create as many fetch groups as you like in the meta data (with
JDO
Genie anyway). I think it is much better to get tuning information likethis
out of the code. It should be added externally much like you add indexesto
database tables in response to query search requirements. I understandthat
sometimes you will need programatic control but mostly it is better notto
pollute the code.
JDO 2.0 is going to standardize the concept of a use-case. This willdelimit
business operations to the JDO implementation so it can applyappropriate
meta-data defined fetch groups or locking strategies. You will be ableto
use a vendor supplied tool to analyze the performance of yourapplication
and construct fetch groups for different use-cases (businessoperations). No
change to the code is necessary.
Here is an example:
CODE
pm.beginUseCase("com.peacetech.sales.displayOrder");
POClass o = (POClass)pm.getObjectById(oid, true);
.... other JDO code ....
pm.endUseCase();
The meta data for the use-case will specify the fetch group to use when
looking up the instance (and locking behaviour etc.). Other use-casescan
have different settings. Only the being/end calls are needed in the codeto
make this happen.
Note that this is a very long way from being finalized. I have just madeup
this example and how it works in JDO 2.0 is likely to be different.
Use-case support will show up in JDO Genie beta releases soon. Wealready
have powerful performance monitoring and analysis support in our GUI
Workbench and very flexible fetch groups.
Cheers
David
Here's my opinion
David,
Thank you for your response. Multiple fetch groups do give moreflexibility
(I do not believe Kodo supports it though) but does not alter myposition
>>
I do not want to pollute my metadata with tons of fetch groups creating
dependencies between my code and those fetch groups. JDOQL languagebeing
what it is already creates unavoidable dependency between field namesfilter
strings so I want to keep it the same way with other things which are
essentially references to persistent fields (Disconnected instancesdepth
control, Eagar fetching ....)
As for polluting my code. I want to assure you everything configurablewill
not be in my code but in JNDI or config files. As long as JDO givesclear
API for expressing graph path selection
Use case concept ties nicely with Graph Path selection concept. In factthis
GraphPaths class along with some additional options is your use case.
It is much easer for me to refactor and keep in sync field names and my
GraphPath than fetch groups.
Alex
"Abe White" <[email protected]> wrote in message
news:[email protected]...
I think the basic idea you've suggested is a good one. We'll certainly
consider it for a future release. The JDO 2 spec team is also
pondering
these problems...
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com