On 6/22/2012 5:04 AM, Steve Ebersole wrote:
> FetchParent extends From. Its not a conflict. Well except to this Java 6 compiler bug, which maybe is your point.
>
It is the other way around -- From extends FetchParent
>
> On Thu 21 Jun 2012 03:52:03 PM CDT, Linda DeMichiel wrote:
>>
>>
>> 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.
>>>>>>>>>>>>