Skip to main content

[jsr338-experts] Re: JPQL joins and ON keyword

  • From: Linda DeMichiel <linda.demichiel@...>
  • To: jsr338-experts@...
  • Cc: Steve Ebersole <steve.ebersole@...>
  • Subject: [jsr338-experts] Re: JPQL joins and ON keyword
  • Date: Fri, 22 Jun 2012 09:31:52 -0700
  • Organization: Oracle Corporation



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.



[jsr338-experts] Re: JPQL joins and ON keyword

Steve Ebersole 06/08/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Linda DeMichiel 06/18/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Steve Ebersole 06/19/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Linda DeMichiel 06/20/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Steve Ebersole 06/21/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Linda DeMichiel 06/21/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Steve Ebersole 06/21/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Linda DeMichiel 06/21/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Steve Ebersole 06/22/2012

[jsr338-experts] Re: JPQL joins and ON keyword

Linda DeMichiel 06/22/2012
 
 
Close
loading
Please Confirm
Close