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: Thu, 21 Jun 2012 13:52:03 -0700

On 6/21/2012 11:54 AM, Steve Ebersole wrote:
> Sorry, but I am not understanding you. How would getParent() conflict? They both return From. There is no covariant
> returns there.
>

Fetch.getParent() returns FetchParent, not From.


> On Thu 21 Jun 2012 11:58:57 AM CDT, Linda DeMichiel wrote:
>>
>>
>> On 6/21/2012 5:44 AM, Steve Ebersole wrote:
>>> Hard to say exactly without access to the bug we cannot see ;)
>>>
>>> But my understanding is that the bug is with compiling convariant
>>> returns for methods on interfaces. getParent() return
>>> is non-dynamic.
>>>
>>
>> My point was that independent of the earlier bug, having Fetch extend
>> Join resulted in conflicting getParent() methods.
>> Did I misunderstand what you were proposing?
>>
>>> On Wed 20 Jun 2012 05:00:57 PM CDT, Linda DeMichiel wrote:
>>>>
>>>>
>>>> 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.
>>>>>>>>>>