db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-554) JDO2.2 : Dynamic fetch groups
Date Mon, 11 Aug 2008 16:42:44 GMT

    [ 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.


Mime
View raw message