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