Date: Mon, 17 Dec 2012 11:07:01 -0800
Hello,
>> Can you please let me know whether you support this change or not.
+1
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 http://openjpa.apache.org/
JPA Expert Group Member
Application & Integration Middleware
From: Linda DeMichiel <linda.demichiel_at_oracle.com>
To: jsr338-experts_at_jpa-spec.java.net
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
extension.
>
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 http://java.net/jira/browse/JPA_SPEC-40
>>>> 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
>>> rainer.schweigkoffer_at_sap.com 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)