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 (JIRA)" <ji...@apache.org> on 2007/11/25 18:34:43 UTC
[jira] Created: (JDO-554) JDO2.2 : Dynamic fetch groups
JDO2.2 : Dynamic fetch groups
-----------------------------
Key: JDO-554
URL: https://issues.apache.org/jira/browse/JDO-554
Project: JDO
Issue Type: New Feature
Components: api2, api2-legacy, specification
Reporter: Andy Jefferson
>From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
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)"
Comments by Erik Samson
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.
Comments by Matthew Adams
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.
Comments by Christiaan:
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.
Comments by Craig Russell:
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)
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: jdo-554.patch
First draft of complete API. What's missing/wrong?
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623359#action_12623359 ]
Andy Jefferson commented on JDO-554:
------------------------------------
DataNucleus SVN (and nightly build) passes all TCK tests.
fetchgroup.conf is now part of configurations.list in Apache JDO SVN
PS. Does FetchGroup also need to go into api2-legacy? It isn't there currently, and I don't see anything JDK1.5 specific in it.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620369#action_12620369 ]
Craig Russell commented on JDO-554:
-----------------------------------
I think we need to be careful about managing the scope of FetchGroups. Changing a FetchGroup in the PMF has global ramifications, as it would affect every PM related to that PMF.
I'd like to examine the use cases. The first one that comes to mind is an application that wants some specific behavior that is not defined in metadata, such as adding a specific field or set of fields to a FetchPlan so the fields are automatically fetched in the scope of this application's usage. For this use case, the ability to add new fetch groups scoped to the PM suffices, because the existing addFetchGroup method can add the new fetch group to the fetch plan in use by the PM.
So I'm fine with
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 or property
FetchGroup remove(String fieldName); // Remove a field or property
boolean hasField(String fieldName); // field or property name, same as getFieldNames.contains(fieldName) so do we need it?
String[] getFieldNames();
void setPostLoad(boolean postLoad);
boolean getPostLoad();
}
Scoping FetchGroup to PM would require a factory in PM, such as FetchGroup createFetchGroup(Class cls, String name) and FetchGroup findFetchGroup(Class cls, String name) that might be combined: FetchGroup getFetchGroup(Class cls, String name) that does both.
And I'd be happy to add some convenience methods to FetchGroup as Eric Samson suggests, by making it possible to add and remove default fetch group fields, primitive fields, reference fields, and multi-valued fields. Maybe something like this:
FetchGroup addCategory("default"); // define constants using Enum or Strings in javax.jdo.Constants
And having a language to specify fetch groups and/or fetch plans is a cool idea. I could see this used in properties, xml, and API.
Regarding Matthew's suggestion adding Field parameters, I don't think this translates well because JDO treats field names and property names equivalently and adding Method parameters would just make it more obscure.
Regarding new methods in PMF, we have a scope issue, a security issue, and a concurrency issue. Any old application that changes fetch groups can affect other applications. The method would need to be protected, just as we protect PMF.close. Concurrency is an issue when fetch groups are changing underneath an application, especially when using the LOAD_FIELDS and UNLOAD_FIELDS flags. An application assumes that a specific set of fields is being loaded or unloaded, and some other application changes the behavior in the middle of a transaction?
Bottom line:
I'm happy with dynamically defining new fetch groups and scoping them to PM. This would be a good start for this round.
I'd be delighted to have a language to define fetch groups that isn't based on xml, so the definitions could be added to a jdoconfig.xml or a properties file or used in the API.
I'm not so keen on global scope (PMF-wide) for fetch groups but I'm open to discussing use cases.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623382#action_12623382 ]
Craig Russell commented on JDO-554:
-----------------------------------
Very cool.
The discussion about api2-legacy is timely. There are other features that would also need to go into the legacy code as well. Just need volunteers...
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621219#action_12621219 ]
Andy Jefferson commented on JDO-554:
------------------------------------
Re: PMF scope. Applications that use PM-per-request (hence short lifetime) would have to define and use FetchGroups each time a request comes in. This is why having a PMF scope was proposed. Obviously care has to be taken in terms of how it is scoped. The intention, and how it is implemented currently in DataNucleus is that when a user adds a FetchGroup to a PM FetchPlan it copies it, hence any subsequent updates to the PMF FetchGroup are not reflected in the FetchPlan of the PM.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: FetchGroup Lifecycle.JPG
I thought I'd try to describe the life cycle of a FetchGroup under the proposed API.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: jdo-554.patch
This is a proposed FetchGroup interface.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: jdo-554.patch
Updated per Andy's comments. Still looking for comments on the add/remove by category.
Do we have the right categories? Is there a difference between BASIC and DEFAULT?
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621296#action_12621296 ]
Craig Russell commented on JDO-554:
-----------------------------------
I can see the need to dynamically alter the behavior of (tune) a running system (PMF).
I believe that we can do both local changes to the PM's fetch groups and also promote the fetch groups to the PMF.
Here's what we can do with PMF: to add/replace the definition of a group of FetchGroups:
PersistenceManagerFactory {
...
void addFetchGroups(FetchGroup... groups);
void removeFetchGroups(FetchGroup... groups);
FetchGroup[] getFetchGroups();
}
The methods would need to serialize among themselves (to avoid race conditions). To avoid problems, the getFetchGroups method would need to return copies of FetchGroup instances, or have some way to mark a FetchGroup instance as readonly. For example, add to FetchGroup: boolean isReadOnly() and void setReadOnly().
Comparing FetchGroup instances would be done by identity comparison of the Class instance and equality testing on the name of the fetch group.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell reassigned JDO-554:
---------------------------------
Assignee: Andy Jefferson
The patch for the API and TCK sources is complete and checked in. The config file fetchgroup.conf is checked in but since it doesn't pass yet, the master config list was not updated.
svn commit -m "JDO-554 Add interface javax.jdo.FetchGroup, updates to PersistenceManager and PersistenceManagerFactory, signatures, test case, and configuration file" tck2 api2
Adding api2/src/java/javax/jdo/FetchGroup.java
Sending api2/src/java/javax/jdo/PersistenceManager.java
Sending api2/src/java/javax/jdo/PersistenceManagerFactory.java
Adding tck2/src/conf/fetchgroup.conf
Sending tck2/src/conf/jdo-2_2-signatures.txt
Adding tck2/src/java/org/apache/jdo/tck/api/fetchgroup
Adding tck2/src/java/org/apache/jdo/tck/api/fetchgroup/FetchGroupTest.java
Transmitting file data ......
Committed revision 685671.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: jdo-554.patch
I've added a test case that compiles but who knows if it actually tests anything?
Also added hashCode and equals with javadoc for the requirements of implementation classes.
Might be useful if you like "test first" strategy.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell resolved JDO-554.
-------------------------------
Resolution: Fixed
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633843#action_12633843 ]
Andy Jefferson commented on JDO-554:
------------------------------------
I've applied the FetchGroup API changes onto api2-legacy. Without this anyone using DataNucleus would be unable to do anything when using JDK1.3/1.4. No plans to apply the TCK changes across to tck2-legacy.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: jdo-554.patch
A few updates.
Javadoc is now self-consistent.
SecurityException is thrown for any of the PersistenceManagerFactory methods that manipulate FetchGroups. The factory method on PersistenceManager does not require security, since it affects only the PersistenceManager.
Methods to add/remove multiple members of the FetchGroup have been added.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621442#action_12621442 ]
Andy Jefferson commented on JDO-554:
------------------------------------
Re: FetchGroup addCategory/removeCategory.
If the user adds ALL *and* RELATIONSHIP and then removes RELATIONSHIP does that mean that ALL are selected still ? or that ALL-RELATIONSHIP ? Maybe just have setCategory() so it gives people a start point for members, and then they can add/remove, and add category of BASIC+RELATIONSHIP as an option (so they have little reason to need more than 1 category).
Re: PMF interface.
Add getFetchGroup(Class cls, String name) ? so the user can get just the one they require.
What about removeAllFetchGroups() ? so they can just remove all without having to get them first.
To create a new FetchGroup the user can't do it via the PMF ? If you add the getFetchGroup(Class, String) on PMF then the user can create locally on the PM, or globally on the PMF.
If they create it via a PM, does this FetchGroup then become available in the PMF ? or just available within the PM ? If the user then creates a similarly named FetchGroup on the PMF for the same class which takes precedence? (the one on the PM?)
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623058#action_12623058 ]
Craig Russell commented on JDO-554:
-----------------------------------
I think Date should be a basic type, since the intent is things that are represented as a simple mapping of a single column. Here's a proposed update to the javadoc:
/**
* For use with {@link #addCategory} and {@link #removeCategory} calls.
* This category includes members of all primitive and immutable
* object class types as defined in section 6.4 of the specification,
* including String, Locale, Currency, BigDecimal, and BigInteger;
* as well as Date and its jdbc subtypes and Enum types.
* @since 2.2
*/
public static final String BASIC = "basic";
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621496#action_12621496 ]
Craig Russell commented on JDO-554:
-----------------------------------
> Re: FetchGroup addCategory/removeCategory.
What I had in mind was very simple. At the time the add/remove method is called, the category is resolved to members and those members would be added/removed. So there is no "history". I'll try to elaborate the methods to clarify what I meant and then we can discuss whether that's good or not.
> Re: PMF interface.
I deliberately omitted the getFetchGroup from PMF because I was focused on the use case where the user is just working with the local fetch groups. But I see that if you are just interested in changing the global fetch groups, you might not even have a PM. I'll add the method to PMF.
And removeAllFetchGroups makes sense if you're rebuilding the entire thing from zero. I'll add the method to PMF.
> If they create it via a PM, does this FetchGroup then become available in the PMF ? or just available within the PM ?
I had the idea that any fetch group defined at the PM level would hide the identical fetch group defined at the PMF level, until the fetch group was added to the PMF via the PMF addFetchGroups method, at which point there would not be a local PM version because the fetch group was now a PMF global object.
> If the user then creates a similarly named FetchGroup on the PMF for the same class which takes precedence? (the one on the PM?)
If after migrating the fetch group to the PMF, if the user did PM.getFetchGroup on the same class and member, that newly created fetch group would hide the global PMF fetch group.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: jdo-554.patch
Right you are. Patch contains the fix.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622496#action_12622496 ]
Andy Jefferson commented on JDO-554:
------------------------------------
DataNucleus SVN and nightly build jars all now build against jdo2-api-2.2-SNAPSHOT.jar. TCK tests run, but all but one fail since those are for PM-based dynamic fetch groups!, and DataNucleus currently implements PMF-based groups only.
For reference the following issue will provide the remaining support, http://www.jpox.org/servlet/jira/browse/NUCCORE-100
and will be done before AccessPlatform 1.0.final release at start of Sept.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622822#action_12622822 ]
Andy Jefferson commented on JDO-554:
------------------------------------
Also "BASIC" is defined (in FetchGroup javadocs) as
"This category includes members of all basic (primitive and immutable object class) types as defined in section 6.4 of the specification, including String, Date and its jdbc subtypes, Locale, Currency, and Enum types."
n Section 6.4.3 Date does not feature as immutable, because it isn't. So either
* the descriptive for "BASIC" is incorrect and should be something like "all non-relation single-valued members", or
* in the list of members for the BASIC category "hiredate" shouldn't appear.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: jdo-554.patch
Changes include:
Added methods set/getFetchDepth to FetchGroup.
Updated javadoc for DEFAULT to reflect that using this category will use the definition of the default fetch group from metadata or annotations and will not be affected by any redefinition via API.
Updated javadoc for ALL and DEFAULT to reflect that they will copy the fetch-depth from the default fetch group members.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Jefferson updated JDO-554:
-------------------------------
Fix Version/s: JDO 2 maintenance release 2
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623073#action_12623073 ]
Craig Russell commented on JDO-554:
-----------------------------------
> also in the test you helpfully added the relevant bit of Employee/Person classes with the fields but phoneNumbers/address haven't been transferred to the list(s) of expected members
Right.
> 1. testCategoriesInterface assumes that IEmployee is a persistent interface whereas in fact it isn't. Should this be PIEmployee?
This test was renamed and turned into a failing case, and PIEmployee is now used for a positive test.
> 2. testAddMember has its final check for the number of members yet seems to be 1 behind with the size. If i is 0 then there should be (i+1) members. Maybe testRemoveMember has something similar? not got that far yet.
I've looked at this, and testAddMember has been fixed to expect one more than the index. But testRemoveMember should be correct as is.
I've checked in a new version with more diagnostics.
svn commit -m "JDO-554 Added diagnostics, fixed errors"
Sending tck2/src/java/org/apache/jdo/tck/api/fetchgroup/FetchGroupTest.java
Transmitting file data .
Committed revision 686437.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621893#action_12621893 ]
Craig Russell commented on JDO-554:
-----------------------------------
> Re: categories. Difference between BASIC and DEFAULT?, the user may have put some relation field in the DFG so they can be considered different. The provided categories cover all requirements I'd have.
The default fetch group is always defined and might be redefined by the user in metadata. But it is also the name of a fetch group that the API can redefine. I'd be ok if we define DEFAULT category as the definition from metadata and not the definition in the PM or PMF.
Also, I overlooked the fetch-depth attribute that needs to be associated with a member of a fetch group.
I'd propose adding this to FetchGroup:
void setFetchDepth(String memberName, int fetchDepth);
int getFetchDepth(String memberName);
> Behaviour: In terms of applying the dynamic fetch groups to the FetchPlan, when a user calls FetchPlan.addGroup(...) this will add any static group of that name, and also any dynamic group of that name. Similarly with setGroup, setGroups, clearGroups, etc.
ok.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621716#action_12621716 ]
Andy Jefferson commented on JDO-554:
------------------------------------
API looks good to me.
Re: categories. Difference between BASIC and DEFAULT?, the user may have put some relation field in the DFG so they can be considered different. The provided categories cover all requirements I'd have.
Behaviour : In terms of applying the dynamic fetch groups to the FetchPlan, when a user calls FetchPlan.addGroup(...) this will add any static group of that name, and also any dynamic group of that name. Similarly with setGroup, setGroups, clearGroups, etc.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621916#action_12621916 ]
Andy Jefferson commented on JDO-554:
------------------------------------
Hi Craig,
shouldn't those new methods be
setRecursionDepth()
getRecursionDepth()
to match the name in metadata (XML/annotations) ?
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-554:
------------------------------
Attachment: jdo-554.patch
Update test with negative tests.
Any comments on the test case? Should we split the test case into a few classes? Positive versus negative?
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622626#action_12622626 ]
Andy Jefferson commented on JDO-554:
------------------------------------
Hi Craig, also in the test you helpfully added the relevant bit of Employee/Person classes with the fields but phoneNumbers/address haven't been transferred to the list(s) of expected members
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622572#action_12622572 ]
Craig Russell commented on JDO-554:
-----------------------------------
Hehe, this is the problem with test first. Thanks for the review of the test cases.
> 1. testCategoriesInterface assumes that IEmployee is a persistent interface whereas in fact it isn't. Should this be PIEmployee?
Yes, indeed. This test should be retained and turned into a failing case, and PIEmployee be used for a positive test.
> 2. testAddMember has its final check for the number of members yet seems to be 1 behind with the size. If i is 0 then there should be (i+1) members. Maybe testRemoveMember has something similar? not got that far yet.
I'll take a closer look at this; I expect you're right. I thought about testRemoveMember with the size and thought I got that right, but for sure testAddMember has a problem.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622566#action_12622566 ]
Andy Jefferson commented on JDO-554:
------------------------------------
Two problems so far with the TCK tests (DataNucleus nightly build is up-to-date if wanting to try) :-
1. testCategoriesInterface assumes that IEmployee is a persistent interface whereas in fact it isn't. Should this be PIEmployee?
2. testAddMember has its final check for the number of members yet seems to be 1 behind with the size. If i is 0 then there should be (i+1) members. Maybe testRemoveMember has something similar? not got that far yet.
> JDO2.2 : Dynamic fetch groups
> -----------------------------
>
> Key: JDO-554
> URL: https://issues.apache.org/jira/browse/JDO-554
> Project: JDO
> Issue Type: New Feature
> Components: api2, api2-legacy, specification
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 2 maintenance release 2
>
> Attachments: FetchGroup Lifecycle.JPG, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch, jdo-554.patch
>
>
> From the Apache JDO jdo-dev mailing list, to register the issue for a subsequent JDO release, and holder for any further discussion
> 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)"
> Comments by Erik Samson
> 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.
> Comments by Matthew Adams
> 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.
> Comments by Christiaan:
> 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.
> Comments by Craig Russell:
> 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)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.