In order to support this, we must have the ability to define named fetch
plans in metadata, and then have the ability apply them to blocks of
application code.
Definition of a FetchPlan in metadata
============================
I would propose that fetch plans can be defined at the <jdo> element
level. For example:
<jdo>
<fetch-plan name="myFetchPlanName" fetch-size="3"
detach-load-fields="true" detach-unload-fields="true"
max-fetch-depth="2">
<fetch-group name="someFetchGroupName"/>
<fetch-group name="someOtherFetchGroupName"/>
</fetch-plan>
</jdo>
Allowable variations would be to allow a user to supply a
comma-delimited list of fetch group names:
<jdo>
<fetch-plan name="myFetchPlanName" fetch-size="3"
detach-load-fields="true" detach-unload-fields="true"
max-fetch-depth="2">
<fetch-group names="someFetchGroupName,someOtherFetchGroupName"/>
</fetch-plan>
</jdo>
or even do it at the fetch-plan level:
<jdo>
<fetch-plan name="myFetchPlanName"
fetch-groups="someFetchGroupName,someOtherFetchGroupName" fetch-size="3"
detach-load-fields="true" detach-unload-fields="true"
max-fetch-depth="2"/>
</jdo>
Default value for fetch-size, detach-load-fields, detach-unload-fields,
max-fetch-depth would be the same as spec-defined defaults.
It would also be good to define a new method on PersistenceManager:
FetchPlan getFetchPlan(String fetchPlanName)
This method would retrieve a FetchPlan defined in the metadata. An
attempt to get an unnamed fetch plan could either return null or throw,
depending upon how vigilant we want the API to be. I'm not sure which
way I prefer.
Use of FetchPlan on application code blocks
================================
There seem to be several ways to make named fetch plans effective, in
order of decreasing intrusiveness in the source code:
1. Method on PersistenceManager: void useFetchPlan(String
fetchPlanName);
This would allow the specification of a single fetch plan to begin to be
used wherever appropriate (query, navigation, getObjectById, etc).
There could be a concomitant method on PersistenceManager: void
stopFetchPlan(String fetchPlanName), if this method were deemed
necessary.
2. Class- and/or method-level JDO annotation @UseFetchPlan
If a class is annotated with @UseFetchPlan, it would indicate to the JDO
implementation that any use of a PM within methods of the class should
use the given fetch plan. If a method is so annotated, then use of a PM
within that method will use the given fetch plan, overriding any fetch
plan that may have been set at the class level.
This would have some kind of overhead, because the JDO implementation
would have to use reflection and the current call stack to determine
whether the annotation were present for the current method and/or class
and, if so, which fetch groups actually need to be used. This may
defeat the purpose of tuning if it turns out that parsing stack traces
is a significant performance hit when compared to not using the fetch
plans at all or just having the user specify them via standard means
visible in the source code (pm.getFetchPlan().addGroup(...)... or
pm.useFetchPlan(...)).
3. Class- or method-level expression in metadata
This would allow the same behavior as annotations above, but could use
an AOP-style pointcut expression in the metadata to indicate the
behavior. Location of this metadata is TBD, but it shouldn't be on the
<class> element, because that is the element used to describe persistent
classes, not application classes, and it is application classes to which
this behavior is being applied.
4. Defining on queries defined in metadata
This would restrict the use of fetch plans declared in metadata to
queries that are defined in metadata. This would be fairly simple for
an implementation to support, as it would simply cause the
implementation to ensure that the fetch plan identified in the query's
metadata is effective for that query's execution, just as if the user
had made all fetch groups defined in the fetch plan active for the
current PM.
This would avoid any reliance on reflection and allow the implementation
to set the active fetch plans upon Query materialization.
Thoughts?
--matthew
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 15, 2006 3:58 PM
To: JDO Expert Group; Apache JDO project
Subject: Small feature for JDO maintenance release
I'd like to consider adding a way for a query in metadata to
specify the fetch plan to be used with that query. And possibly a way
for the application to define on an application basis which fetch plan
to be used. Perhaps a class and method name binding to a fetch plan, so
any query or retrieval made with that class and method on the stack
would use that fetch plan. This allows non-intrusive specification of
the fetch plan to be used.
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
