users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: JPQL joins and ON keyword

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Wed, 20 Jun 2012 15:00:57 -0700

On 6/19/2012 10:50 AM, Steve Ebersole wrote:
> We'll have to agree to disagree I guess (unfortunately for me). I guess we are too far down the current path.
>
> Anyway, a related concern I would like to raise is the on(...) method definitions on Join and Fetch. Join and Fetch are
> unrelated interface hierarchies. In Hibernate at least I decided to combine those interface hierarchies so I have an
> interface JoinImplementor that extends both Joing and Fetch (a Fetch really is just a specialization of a Join). Now in
> JPA 2.1 with the addition of these on(...) methods, we now hit a bug in javac in every Java 6 JDK (Oracle on all
> platforms, OpenJDK, Mac JDK). The original bug report (6294779) is unfortunately no longer accessible on the Oracle Java
> bug tracker, although google searches find tons of references to it.. The bug was fixed in Java 7's JDK.
>
> Any possible way to get Fetch to extend Join?
>

Um, what about the conflicting getParent() methods?

> On Mon 18 Jun 2012 05:15:18 PM CDT, Linda DeMichiel wrote:
>>
>>
>> On 6/8/2012 11:23 AM, Steve Ebersole wrote:
>>> Also, in using ON to both (1) define the join conditions in an ad-hoc
>>> join (not supported in JPA) and (2) supply extra
>>> join conditions to an association join, we have a situation where
>>> keywords are used for 2 different purposes. I'd really
>>> like this to be changed. I think it will be completely confusing to
>>> users if and when JPA decides to allow ad-hoc joins.
>>>
>>
>> I'm afraid I don't agree. If someone understands the semantics of SQL
>> ON conditions, I don't see
>> that they wouldn't also be able to understand the difference between
>> its effect on our relationship
>> joins vs on ad hoc joins, were we to add them.
>>
>>
>>> On Thu 24 May 2012 02:51:21 PM CDT, Steve Ebersole wrote:
>>>> Cool, thanks for the pointer.
>>>>
>>>> So the answer to the question asked there about why a different
>>>> keyword is "needed", is that its not "needed". But it makes things
>>>> much cleaner to specify in EBNF and much more efficient to parse.
>>>> Again the issue is not really evident today because JPQL only allows
>>>> association joins. If and when it allows ad-hoc (non-association)
>>>> joins thats when this becomes an issue.
>>>>
>>>> Like I mentioned in my initial email its a difference between
>>>> syntactic analysis versus semantic analysis of the query. Syntactic
>>>> differences are much easier to describe in an EBNF and much more
>>>> efficient to parse.
>>>>
>>>>
>>>> On Thu 24 May 2012 02:31:14 PM CDT, Linda DeMichiel wrote:
>>>>> Hi Steve,
>>>>>
>>>>> Please see the thread that started March 11, 2011. This should be
>>>>> available in the archives.
>>>>>
>>>>> -Linda
>>>>>
>>>>>
>>>>> On 5/24/2012 12:09 PM, Steve Ebersole wrote:
>>>>>> I was not a member on the list when this was originally discussed, so
>>>>>> I apologize for dragging up a potentially old
>>>>>> discussion. But I wanted to caution against the use of 'ON' as a
>>>>>> keyword in the way it is currently proposed in the
>>>>>> specification.
>>>>>>
>>>>>> The problem is ambiguity in cases where the provider supports 'ON' as
>>>>>> a more SQL-like ad-hoc joining capability between
>>>>>> unassociated entities. In such cases the keyword 'ON' is often the
>>>>>> only SYNTACTIC disambiguation between the 2 cases.
>>>>>>
>>>>>> Consider:
>>>>>>
>>>>>> select s.name, count(p.id)
>>>>>> from javax.persistence.ex.Supplier s
>>>>>> inner join javax.persistence.ex.Product p
>>>>>> on s.id = p.supplierId
>>>>>>
>>>>>> So here we have Supplier and Product as unrelated classes (no mapped
>>>>>> association). The problem is that structurally
>>>>>> (syntactically) the query is completely ambiguous with the proposed
>>>>>> form:
>>>>>>
>>>>>> select s.name, count(p.id)
>>>>>> from javax.persistence.ex.Supplier s
>>>>>> inner join s.product
>>>>>> on p.status = 'inStock'
>>>>>>
>>>>>> where the join is an association join.
>>>>>>
>>>>>> When parsing queries its always better to disambiguate based on
>>>>>> syntax whenever possible. Here we instead have to fall
>>>>>> back to semantic disambiguation, which essentially means that we now
>>>>>> have to hold parsing and interpret the meaning of
>>>>>> the 2 sides of the join in oder to know what type of join it is.
>>>>>>
>>>>>> Not to mention that it is odd in my opinion for developers versed in
>>>>>> SQL to see ON used here. The first thought is
>>>>>> whether that adds to the SQL ON clause defined by the association
>>>>>> mapping or whether that replaces it. So we lose a
>>>>>> little intuitiveness.
>>>>>>
>>>>>> I'd really rather see a different keyword here. In Hibernate we chose
>>>>>> WITH as the keyword for this for just these reasons:
>>>>>>
>>>>>> select s.name, count(p.id)
>>>>>> from javax.persistence.ex.Supplier s
>>>>>> inner join s.product
>>>>>> with p.status = 'inStock'
>>>>>>
>>>>>> there I think it is very obvious that the condition is added to the
>>>>>> SQL ON clause.
>>>>>>