openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Adams <matt...@matthewadams.me>
Subject Re: OpenJPA rock and fetch plan is a killing feature.
Date Tue, 01 Feb 2011 15:10:38 GMT
Yes, agreed.  It has been standardized in JDO since version 2.0, many
years ago, and OpenJPA, formerly being KodoJDO, a JDO implementation,
of course has had fetch plans since that time.  All other ORM
implementations of JDO, most notably DataNucleus, also support this
feature.  Additionally, since JDO does not mandate a SQL back end,
there are also nonrelational back ends supported via JDO that also
support the notion of fetch plans.

The key difference in JDO's approach, IMHO, is that JDO has always
clearly separated three components of a query:  the projection, the
filter, and the fetch depth.  Each of these is a separate concern in
JDOQL, whereas in JPQL, the use of joins is required to achieve the
same affect.  The projection is simply the shape of the data that will
be returned; by default, it is a collection of the candidate class
used in the query.  The filter is pretty easy to understand:  it's
basically the "where" part of the query, specifying the criteria that
must be met in order for data to be returned.  The fetch plan
specifies the breadth and depth of the object graph, usually but not
always rooted in instances of the candidate class, returned.
Basically, whereas your projection (instances of Foo, say) and your
filter (where foo.bar.startsWith("blah"), say) may not change in a
query, the fetch plan can vary wildly by use case.  In JPA 1.0 & 2.0,
it boils down to having to change your query solely in the name of
optimization, which JDO feels you shouldn't have to do.  The
projection and the filter can remain the same, but you can get back a
much broader & deeper or narrower & shallower object graph depending
on the current fetch plan.

Definitely good stuff.

-matthew

On Mon, Jan 31, 2011 at 4:18 PM, Jean-Baptiste BRIAUD -- Novlog
<j-b.briaud@novlog.com> wrote:
> http://www.avaje.org/ebean/introquery_join.html
>
> Fetch path, fetch plan, ... : the same good idea with probably small implementation differences
in different products.
>
> On 31 janv. 2011, at 20:40, Daryl Stultz wrote:
>
>> On Mon, Jan 31, 2011 at 2:26 PM, Jean-Baptiste BRIAUD -- Novlog <
>> j-b.briaud@novlog.com> wrote:
>>
>>> Conclusion : thanks OpenJPA, you're the only one I know with such powerful
>>> feature.
>>>
>>> Ebean tracks calls to queries and auto-tunes the queries according to the
>> properties that are accessed on the resulting object graph (in subsequent
>> calls). No fetch plan needed.
>>
>> --
>> Daryl Stultz
>> _____________________________________
>> 6 Degrees Software and Consulting, Inc.
>> http://www.6degrees.com
>> http://www.opentempo.com
>> mailto:daryl.stultz@opentempo.com
>
>



-- 
mailto:matthew@matthewadams.me
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@gmail.com
msn:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

Mime
View raw message