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.
>>>>