You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Andy Jefferson <an...@jpox.org> on 2007/11/13 11:32:47 UTC
JDO2.1/2.2 Proposal : Dynamic Fetch Groups
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)
Re: JDO2.1/2.2 Proposal : Dynamic Fetch Groups
Posted by Christiaan <ch...@hotmail.com>.
Good idea, I've already been needing this.
May be also think about an option to restore to a fetchGroup to a state
before you start changing it (possibly via supporting clone()) or reset to
configuration defined in JDO file.
kind regards,
Christiaan
--
View this message in context: http://www.nabble.com/JDO2.1-2.2-Proposal-%3A-Dynamic-Fetch-Groups-tf4797003.html#a13839872
Sent from the JDO - Development mailing list archive at Nabble.com.
RE: JDO2.1/2.2 Proposal : Dynamic Fetch Groups
Posted by Eric Samson <er...@xcalia.com>.
Hi Andy,
This is a good initiative, thank you.
JDO 2 needs alternate ways to define fetch plans.
Some food for thoughts here:
· possibility to add the DFG of a class into a fetch group
· possibility to add all fields of a class into a fetch group
· possibility to add all primitive fields of a class into a fetch group
· possibility to add all reference fields of a class into a fetch group
· possibility to add all collections fields of a class into a fetch group
· possibility to remove all primitive fields of a class into a fetch group
· possibility to remove all reference fields of a class into a fetch group
· possibility to remove all collections fields of a class into a fetch group
· possibility to create a global fetch plan without fetch groups at all
pm.setFetchPlan( "Person( name,age,
address( {dfg} ,
country( {all} , -flagIMG ) ),
accounts( {simple} , +{references} ) )" ) ;
Person actually references the candidate class, so I suppose it could be optional.
This method will load name and age from a Person, then will load the configured DFG from the reference to Address, then will load all fields but flagIMG from the reference to Country into address, and finally will load simple fields and unary references to other objects from the collection of Accounts. We should also probably support depth in that mechanism.
Having this “SSFP” (Single String Fetch Plan) will allow to tune the system externally, from JMX or a configuration file for instance.
Many users told me it is quite difficult to define fetch plans from independent fetch groups configured in various classes (and possibly various JDO files). They would like a way to execute a query with a fetch plan defined next to the query, by APIs, or by configuration.
Just my 2 cents.
Rgds,
....: Eric Samson, Founder & CTO, Xcalia
Service your Data!
-----Message d'origine-----
De : Andy Jefferson [mailto:andy@jpox.org]
Envoyé : mardi 13 novembre 2007 11:33
À : jdo-dev@db.apache.org; JDO Expert Group
Objet : JDO2.1/2.2 Proposal : Dynamic Fetch Groups
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)
Re: JDO2.1/2.2 Proposal : Dynamic Fetch Groups
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Andy,
I like the idea of dynamically generating FetchGroups. For a post-2.1
release.
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.
Craig
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!
Re: JDO2.1/2.2 Proposal : Dynamic Fetch Groups
Posted by Matthew Adams <ma...@matthewadams.org>.
You might also consider overloaded methods on interface FetchGroup,
just for completeness:
// (importing java.lang.reflect.Field)
FetchGroup add(Field field);
FetchGroup remove(Field field);
boolean hasField(Field field); // or has(Field) -- I'd consider
better verb
Field[] getFields();
The add & remove methods should throw if the Field isn't contained in
the class.
-matthew
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)