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