Hi,
By "tuning", are you proposing addition of non-fetchplan fields to the
selected fetch plan, or are you also proposing removal of "unused" fields
from the selected fetch plan?
If the proposal includes the removal of unused fields from the fetch plan then
the listener would need to be on any jdoGetXXX/jdoPutXXX calls (rather than
when something was loaded). So would be an AccessListener - do we need to
distinguish between user read and user write of a field for this? Dont think
so.
Presumably somewhere the fetch plan is being updated as a result of the fetch
notifications, so a new fetch group is added "AUTO" with the fetched fields
in ?
Who does the "tuning" ? The implementation ? Something generic in
JDO(Impl)Helper?
Re: UseCase
+1 to the general idea. Needs definition of what is in scope for inclusion in
the "use-case". Obviously current PM props
("multithreaded", "detachAllOnCommit", "IgnoreCache", "queryTimeoutInMillis",
"copyOnAttach", "fetchPlan")
and current Transaction props (optimistic, nontx-read, nontx-write,
restoreValues, retainValues, txnIsolationLevel, txnRollbackOnly) and also
extensions.
Is the use-case definable solely in XML ? or perhaps we have an API too.
Is there only one use-case active and beginUseCase() removes any previous ?
I'd probably prefer
PM.setUseCase(String name);
PM.unsetUseCase();
--
Andy (DataNucleus - http://www.datanucleus.org)
