[jpa-spec users] [jsr338-experts] Re: fetch joins with ON conditions

From: Pinaki Poddar <>
Date: Mon, 17 Dec 2012 11:07:01 -0800

>> Can you please let me know whether you support this change or not.


  I prefer an approach where a syntax (such as
EntityGraph/Subgraph/FetchPlan or whatever whatever other moniker)
describes a subest or view of the entire domain model and then the subset
specification is applied on persistent operations such as find(), merge(),
refresh() etc. Such cascaded behavior/concept already exists in the spec,
we can make that behavior more sophisticated. This approach will provide
an unified as well as extensible means to grow the spec, imo.
  I do not prefer the approach where query takes the dual role of selection
and cascading behavior for load via ON (or, for that matter, FETCH JOIN)
keywords in JPQL.

Regards --

Pinaki Poddar
Chair, Apache OpenJPA Project
JPA Expert Group Member
Application & Integration Middleware

From: Linda DeMichiel <>
Date: 12/14/2012 02:40 PM
Subject: [jsr338-experts] Re: fetch joins with ON conditions

On 12/14/2012 2:29 PM, Steve Ebersole wrote:
> I understand the danger, but still see benefit for advanced users. If we
want to remove it from the spec, I am fine with
> that; ultimately a vendor could still choose to support it as an

They won't be able to support it via the Criteria APIs however.

> On Fri 14 Dec 2012 03:27:59 PM CST, Linda DeMichiel wrote:
>> Thanks Rainer!
>> Can I please hear from more of you on this issue?
>> -Linda
>> On 12/14/2012 3:47 AM, Rainer Kwesi Schweigkoffer wrote:
>>> Linda DeMichiel, am 13 Dec 2012 hast Du um 12:25 zum Thema "[jsr338-
>>> experts] fetch joins with ON conditions" geschrieben :
>>>> We still have the open issue
>>>> regarding problems with fetch joins and ON conditions.
>>>> At this point, I am inclined to remove support for ON conditions
>>>> with fetch joins, since with the proposal for the more general support
>>>> for prefetching in terms of fetch graphs, fetch joins become less
>>>> important in general.
>>>> This would entail removal from the JPQL BNF as well as removal of
>>>> methods on the Fetch interface.
>>>> Can you please let me know whether you support this change or not.
>>> +1
>>> ---
>>> Rainer Schweigkoffer SAP AG Walldorf
>>> Regulatory Compliance TIP Core JI
>>> Core Java Infrastructure Dietmar-Hopp-Allee 16
>>> Technology& Innovation Platform D-69190 Walldorf
>>> Building 3, F.3.14 phone: +49 6227 7 45305
>>> fax: +49 6227 7 821177
>>> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
>>> Vorstand/SAP Executive Board: Werner Brandt, Lars
>>> Dalgaard, Luisa Deplazes Delgado, Bill McDermott (Co-CEO),
>>> Gerhard Oswald, Vishal Sikka, Jim Hagemann Snabe (Co-CEO)
>>> Vorsitzender des Aufsichtsrats/Chairperson of the SAP
>>> Supervisory
>>> Board: Hasso Plattner
>>> Registergericht/Commercial Register Mannheim No HRB 350269
>>> Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse
>>> oder sonstige vertrauliche Informationen enthalten.
>>> Sollten Sie diese E-Mail irrtuemlich erhalten haben, ist
>>> Ihnen eine Verwertung des Inhalts, eine Vervielfaeltigung
>>> oder Weitergabe der E-Mail ausdruecklich untersagt. Bitte
>>> benachrichtigen Sie uns und vernichten Sie die empfangene
>>> E-Mail. Vielen Dank.
>>> This e-mail may contain trade secrets or privileged,
>>> undisclosed, or otherwise confidential information. If you
>>> have received this e-mail in error, you are hereby
>>> notified that any review, copying, or distribution of it
>>> is strictly prohibited. Please inform us immediately and
>>> destroy the original transmittal. Thank you for your
>>> cooperation.

(image/gif attachment: graycol.gif)