db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@datanucleus.org>
Subject Re: Fetch notifications
Date Sat, 28 Mar 2009 11:33:37 GMT
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)

Mime
View raw message