Oh, I missed the
http://java.net/jira/browse/JPA_SPEC-28 reference. +1
for me too on that.
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
>