db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Work in progress: fetch plan
Date Fri, 06 Jan 2006 03:12:05 GMT
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!


Mime
View raw message