From: Pinaki Poddar <ppoddar_at_us.ibm.com>
Date: Thu, 8 Nov 2012 09:39:30 -0800

> We also have a fetch-plan item on our agenda (which I hope to be able to
address in this release, despite the tight timelines)

I support that we explore fetch planning as an independent construct over
the approach of augmenting JPQL to control the access pattern.
A fetch plan as a subsidiary to find() or query operations will allow JPA
to support more sophisticated data access use cases.


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: 11/06/2012 01:56 PM
Subject: [jsr338-experts] Re: outer fetch joins with on-conditions




On 11/1/2012 2:58 PM, Steve Ebersole wrote:
> Oh, I missed the http://java.net/jira/browse/JPA_SPEC-28 reference. +1
for me too on that.
>

The problem is that supporting this opens up a can of worms with
regard to consistency, as was pointed out in
http://java.net/jira/browse/JPA_SPEC-40

I think there are two aspects to consider:

  1) whether this should be supported for more sophisticated developers who
  very intentionally want to use this capability for its side effect in
filtering
  2) whether this will be very error prone for everybody else.

We also have a fetch-plan item on our agenda (which I hope to be able to
address in this release, despite the tight timelines) and that would
provide
a general capability to specify prefetching (and also multi-level
prefetching).

At this point, I'd prefer to err on the side of caution, and not introduce
identification variables on the right hand side of fetch joins.

Yes, do still have the remaining issue pointed out in JIRA issue 40
with regard to allowing single-valued relationship traversal through
path expressions, but I think that can be dealt with by stating in the
specification that it is not supported for use with on-conditions.



> On Thu 01 Nov 2012 12:50:02 PM CDT, Gordon Yorke wrote:
>> Yes as Steve said, currently the use of an ON condition with either an
>> inner or outer fetch join would result in relationship elements being
>> filtered by the ON condition as well.
>>
>> I think the best way to handle this is to add a note to the
>> specification about the behaviour and recommend cache-store-mode set
>> to bypass. Only users who actually want to filter the contents of the
>> relationships would be expected to use the ON clause within a FETCH
>> JOIN. Being able to reduce the number of elements in a relationship
>> during a FETCH JOIN is beneficial in some circumstances.
>> We could also add FETCH JOIN aliasing within the specification.
>> --Gordon
>>
>> On 31/10/2012 4:51 PM, Linda DeMichiel wrote:
>>> I've been having an interesting discussion with a user on the JPA
>>> JIRA with
>>> regard to outer fetch joins. See the issue
>>> http://java.net/jira/browse/JPA_SPEC-40
>>>
>>> The issue is basically whether an outer fetch join with on-condition
>>> can result in an entity whose state/relationships have been
>>> inconsistently
>>> fetched.
>>>
>>> Since we don't currently support the use of identification variables on
>>> the right hand side, I believe that we currently do not have a problem.
>>> Please double-check whether you agree with me on this or not.
>>>
>>> However, the ability to specify identification variables here has
>>> also be requested,
>>> and is something that we could plausibly add in future. See the issue
>>> http://java.net/jira/browse/JPA_SPEC-28
>>>
>>> I'd like input from the group with regard to these issue, and whether
>>> we should consider:
>>>
>>> 1) not supporting outer fetch joins with on-conditions
>>> 2) not (i.e., never) supporting outer fetch joins with the use of
>>> identification
>>> variables on the right hand side
>>> 3) not supporting the use of on-conditions with outer fetch joins
>>> that use
>>> identification variables on the right hand side.
>>> 4) other??
>>>
>>> -Linda
>>