Support JOIN/ON for two root entities

[lukasj]

Currently JPA does not allow root entities after various JOIN clauses which means that especially outer joins cannot be specified and executed without association path. In some cases it may be beneficial when we can join even when the relation is not mapped, e.g. to avoid potentially EAGER One- or @manytoone relationship (LAZY is only hint, not guaranteed).

EclispeLink currently supports such joins and they add a lot of options how to solve some problems with a minimal JPQL change. "EclipseLink also supports usage of the ON clause between two root level objects." See: https://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying/JPQL#ON

Please, consider root entites as candidates for joins.

[lukasj]

@glassfishrobot Commented
Reported by virgo47

[lukasj]

@glassfishrobot Commented
neilstockton said:
+1 for allowing JOIN to be to another "root" element. DataNucleus JPA also provides that IIRC.

But think this won't apply to "FETCH JOIN" which still needs to be along a relation, hence spec needs to distinguish the syntax difference between JOIN and FETCH JOIN.

[lukasj]

@glassfishrobot Commented
c.beikov said:
Hibernate also supports this kind of joins as of version 5.1: http://in.relation.to/2016/02/10/hibernate-orm-510-final-release/

[lukasj]

@glassfishrobot Commented
This issue was imported from java.net JIRA JPA_SPEC-128

[lukasj]

• Issue Imported From: https://github.com/javaee/jpa-spec/issues/128
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @ldemichiel

[gavinking]

To be clear, we're talking about queries like this:

select book.title, publisher.name
from Book book
    join Publisher publisher
        on book.publisher = publisher
where book.title like :titlePattern

Correct?

If so, then this is something that both EclipseLink and Hibernate have supported for quite a long time, and it's something that should be quite trivial to add to the spec.

I would say we can easily do this for 3.2.

[gavinking]

Please review proposal #467, which also cleans up some of the language in that section of the spec.