Work in progress: fetch plan

[Craig L Russell <Cr...@Sun.COM>]

Javadogs,

Here's what I'm working on (the last big JDO 2 issue). I'll address  
the fetch-depth next.

Fetch Plans
A fetch plan defines rules for instantiating the loaded state for an  
object graph. It specifies fields to be loaded for all of the  
instances in the graph. Using fetch plans, users can control the  
field fetching behavior of many JDO APIs. A fetch plan can be  
associated with a PersistenceManager and, independently, with a Query  
and with an Extent.
A fetch plan also defines rules for creating the detached object  
graph for the detach APIs and for automatic detachment at commit with  
DetachAllOnCommit set to true.
A fetch plan consists of a number of fetch groups that are combined  
additively for each affected class; a fetch size that governs the  
number of instances of multi-valued fields retrieved by queries; a  
fetch-depth per field that governs the depth of the object graph  
fetched for that field; and flags that govern the behavior of  
detachment.
The default fetch plan contains exactly one fetch group, "default".  
It has a fetch size of 0, and detachment option DETACH_LOAD_FIELDS.  
The default fetch plan is in effect when the PersistenceManager is  
first acquired from the PersistenceManagerFactory.
With the default fetch plan in effect, the behavior of JDO 2 is very  
similar to the behavior of JDO 1. That is, when instances are loaded  
into memory in response to queries or navigation, only the fields in  
the default fetch group are loaded, and the jdoPostLoad callback is  
executed the first time an instance is fetched from the datastore.  
Upon detachment, fields that are already loaded into the detached  
instances are preserved; fields that have not been loaded are marked  
in the detached instances as not loaded.
This basic behavior is sufficient for the most basic use case for  
detachment, where the detached instances are simply “data transfer  
objects” containing primitive fields. The detached instances can be  
modified in place or serialized and sent to another tier to be  
changed and sent back. Upon being received back, the instances can be  
attached and if there are no version conflicts, the changes can be  
applied to the datastore.
The most common use case for fetch groups is to restrict the fields  
loaded for an instance to the primitive values and avoid loading  
related instances for queries. For more control over the default  
behavior, the “default” fetch group can simply be redefined for  
specific classes. For example, a String field that contains a  
typically large document can be defined as not part of the default  
fetch group, and the field will be loaded only when accessed by the  
application. Similarly, the Order field associated with OrderLine  
might be defined as part of the default fetch group of OrderLine, and  
queries on OrderLine will always load the corresponding Order  
instance as well. This can easily improve the performance of  
applications that always need the Order whenever OrderLine instances  
are loaded.
For explicit detachment, the parameters of the detach method are each  
treated as roots for the purpose of determining the detached object  
graph. The fetch plan is applied to each of the roots as if the other  
roots were not also being detached. The roots and their corresponding  
object graphs are combined and the resulting object graph is detached  
in its entirety.

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

Re: Work in progress: fetch plan

[Craig L Russell <Cr...@Sun.COM>]

Hi Jörg,

Thanks for your comments.

On Jan 6, 2006, at 8:07 AM, Jörg von Frantzius wrote:

> Craig L Russell wrote:
>
>> [..] With the default fetch plan in effect, the behavior of JDO 2  
>> is very similar to the behavior of JDO 1. That is, when instances  
>> are loaded into memory in response to queries or navigation, only  
>> the fields in the default fetch group are loaded, and the  
>> jdoPostLoad callback is executed the first time an instance is  
>> fetched from the datastore. Upon detachment, fields that are  
>> already loaded into the detached instances are preserved;
> The "already" in here sounds a bit to me like a detached instance  
> could preserve state for fields that had been loaded prior to  
> detaching, even when those fields were not contained in the current  
> fetch plan upon detaching. If I remember correctly, this should not  
> be the case?

With the default fetch plan in effect, detachment uses the  
DETACH_LOAD_FIELDS flag (set to true) and the DETACH_UNLOAD_FIELDS  
(set to false) to determine which fields should be preserved in the  
detached instance. So no fields are detached at detach time if they  
were loaded. If this is not the behavior you want, you can set the  
DETACH_UNLOAD_FIELDS flag to true and in this case fields not in the  
current fetch plan will be unloaded.

So I've updated the spec to make this clear:

<working draft>
With the default fetch plan in effect, the behavior of JDO 2 is very  
similar to the behavior of JDO 1. That is, when instances are loaded  
into memory in response to queries or navigation, fields in the  
default fetch group are loaded, and the jdoPostLoad callback is  
executed the first time an instance is fetched from the datastore.  
The implementation is allowed to load additional fields, as in JDO 1.  
Upon detachment, fields that are have been loaded into the detached  
instances are preserved, regardless of whether they were loaded  
automatically by the implementation or loaded in response to  
application access; and fields that have not been loaded are marked  
in the detached instances as not loaded.
</working draft>

Craig
>
> IMHO, just dropping the "already" would make this clearer, or maybe  
> something like
> "Upon detachment, only fields that were contained in the current  
> fetch plan are preserved, all other fields are marked in the  
> detached instances as not loaded."
>
> Regards,
> Jörg
>
> -- 
> __________________________________________________________
> Dipl.-Inf. Jörg von Frantzius  |            artnology GmbH
>                               |                Milastr. 4
> Tel +49 (0)30 4435 099 26      |              10437 Berlin
> Fax +49 (0)30 4435 099 99      |  http://www.artnology.com
> _______________________________|__________________________
>

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

Re: Work in progress: fetch plan

[Jörg von Frantzius <jo...@artnology.com>]

Craig L Russell wrote:

> [..] With the default fetch plan in effect, the behavior of JDO 2 is 
> very similar to the behavior of JDO 1. That is, when instances are 
> loaded into memory in response to queries or navigation, only the 
> fields in the default fetch group are loaded, and the jdoPostLoad 
> callback is executed the first time an instance is fetched from the 
> datastore. Upon detachment, fields that are already loaded into the 
> detached instances are preserved;
The "already" in here sounds a bit to me like a detached instance could 
preserve state for fields that had been loaded prior to detaching, even 
when those fields were not contained in the current fetch plan upon 
detaching. If I remember correctly, this should not be the case?

IMHO, just dropping the "already" would make this clearer, or maybe 
something like
"Upon detachment, only fields that were contained in the current fetch 
plan are preserved, all other fields are marked in the detached 
instances as not loaded."

Regards,
Jörg

-- 
__________________________________________________________
Dipl.-Inf. Jörg von Frantzius  |            artnology GmbH
                               |                Milastr. 4
Tel +49 (0)30 4435 099 26      |              10437 Berlin
Fax +49 (0)30 4435 099 99      |  http://www.artnology.com
_______________________________|__________________________