db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: JDO2.1/2.2 Proposal : Dynamic Fetch Groups
Date Mon, 19 Nov 2007 18:13:10 GMT
Hi Andy,

I like the idea of dynamically generating FetchGroups. For a post-2.1  

Also, I think that we should consider ways to manipulate FetchPlans  
as well, both in programmatic as well as declarative approaches.  
Specifically, I'd like to be able to specify in my configuration the  
FetchPlan to use in a specific application context, e.g. the first  
time a PersistenceManager is used to getObjectById or newQuery, the  
FetchPlan for that use case is looked up from configuration and set  
as the current FetchPlan.

Further, if the application wants a specific FetchPlan, they should  
be able to call a method setFetchPlan with either the name of a  
configured FetchPlan or a FetchPlan to use.

And then, assuming that the FetchPlan must change during some  
interval of application processing, and then reset to the previous  
settings, public void pushFetchPlan(FetchPlan); public void  
pushFetchPlan(String fetchPlanName) and public FetchPlan popFetchPlan 
() would allow a temporary override of the FetchPlan without the  
application having to preserve the settings and update the FetchPlan  
to restore it.

In this light, it might make sense to be able to register FetchPlans  
by name with the PersistenceManagerFactory.


On Nov 13, 2007, at 2:32 AM, Andy Jefferson wrote:

> Below is a proposal that could possibly be included in a JDO2.2 (or  
> in JDO2.1
> if feedback is positive for that, and JPOX already implements it).
> ========================================
> Problem : fetch groups are static, defined in metadata (XML/ 
> annotations).
> Sometimes it would be more convenient to be able to define fetch  
> groups
> dynamically, for example based on user interaction in a web system.
> ========================================
> Proposal :
> We add a new interface defining a FetchGroup, where a FetchGroup has a
> symbolic name and is for a class defining the fields of that class  
> that are
> in the fetch group.
> public interface FetchGroup
> {
>     String getName(); // Symbolic name (as also used in MetaData)
>     String getClassName(); // Class to which this group refers
>     FetchGroup add(String fieldName); // Add a field
>     FetchGroup remove(String fieldName); // Remove a field
>     boolean hasField(String fieldName);
>     String[] getFieldNames();
>     void setPostLoad(boolean postLoad);
>     boolean getPostLoad();
> }
> We allow users to register/deregister their FetchGroups with the PMF
> PersistenceManagerFactory
> {
>     ...
>     void addFetchGroup(FetchGroup grp);
>     void removeFetchGroup(String name, Class cls);
>     FetchGroup createFetchGroup(String name, Class cls);
>     FetchGroup getFetchGroup(String grpName, Class cls);
>     FetchGroup[] getFetchGroups();
>     void clearFetchGroups();
> }
> ========================================
> Usage:
> FetchGroup grp1 = pmf.createFetchGroup("myGroup1", MyClass.class);
> grp1.add("field1").add("field2").add("field4");
> pmf.addFetchGroup(grp1); // FetchGroup registered
> pm.getFetchPlan().setGroup("myGroup1"); // FetchGroup used in this  
> plan
> // FetchPlan now has MyClass {field1, field2, field4}
> We can then also allow dynamic changes like
> pmf.getFetchGroup("myGroup1", MyClass.class).add("field7");
> and this is directly reflected in the FetchPlan
> Possible changes:-
> 1. PMF has createFetchGroup and addFetchGroup and we could merge  
> these so when
> creating a FetchGroup it is added
> 2. Doesnt support "recursion-depth" specification when adding a  
> field to a
> FetchGroup, so we could add a method "add(String fieldName, int  
> depth)"
> -- 
> Andy  (Java Persistent Objects - http://www.jpox.org)

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message