Re: JDO2.1/2.2 Proposal : Dynamic Fetch Groups

[Craig L Russell]

Hi Andy,












Craig

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

I like the idea of dynamically generating FetchGroups. For a post-2.1 release. Also, I think that we should consider ways to manipulate FetchPlans as well, both in programmatic as well as declarative approaches. Specifically, I'd like to be able to specify in my configuration the FetchPlan to use in a specific application context, e.g. the first time a PersistenceManager is used to getObjectById or newQuery, the FetchPlan for that use case is looked up from configuration and set as the current FetchPlan. Further, if the application wants a specific FetchPlan, they should be able to call a method setFetchPlan with either the name of a configured FetchPlan or a FetchPlan to use. And then, assuming that the FetchPlan must change during some interval of application processing, and then reset to the previous settings, public void pushFetchPlan(FetchPlan); public void pushFetchPlan(String fetchPlanName) and public FetchPlan popFetchPlan () would allow a temporary override of the FetchPlan without the application having to preserve the settings and update the FetchPlan to restore it. In this light, it might make sense to be able to register FetchPlans by name with the PersistenceManagerFactory.

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

========================================

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

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


// 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:-

creating a FetchGroup it is added



--
Andy  (Java Persistent Objects - http://www.jpox.org)

Problem : fetch groups are static, defined in metadata (XML/ annotations). Sometimes it would be more convenient to be able to define fetch groups symbolic name and is for a class defining the fields of that class that are pm.getFetchPlan().setGroup("myGroup1"); // FetchGroup used in this plan 1. PMF has createFetchGroup and addFetchGroup and we could merge these so when 2. Doesnt support "recursion-depth" specification when adding a field to a FetchGroup, so we could add a method "add(String fieldName, int depth)"

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

smime.p7s
Description: S/MIME cryptographic signature