summary

MapJoin.key() produces unusable Path object

Description

I'm using MapJoin like this:

The em.createQuery(cq) call throws a NullPointerException:

The same code works fine on EclipseLink.

Seems that the problem is in the MapKeyHelpers.MapKeySource constructor, which calls the super constructor from AbstractPathSource with a null pathSource argument:

This way, the pathSource is initialized to null. Then, AbstractPathSource's getPathIdentifier() will always throw a NPE.

Environment

None

Activity

Show:

Gail Badner

July 10, 2014, 5:58 AM

Closing resolved issued in preparation for releasing 4.3.6.

Aris Tzoumas

April 30, 2014, 7:41 AM

Any plans on fixing this bug? There seems to be an open pull request:
https://github.com/hibernate/hibernate-orm/pull/735

Jarkko Hyöty

April 11, 2014, 10:43 AM

Experiencing the same problem using 4.3.5.Final.

Pavel Lechev

March 10, 2014, 1:26 PM

Edited

We have a specific scenario where queries have to be constructed using both KEY(xyz) function and JOIN abc ON [predicate].

Support for extended JOIN [...] ON [...] was added in 4.3.0 which is great. Unfortunately re-introducing in a different form as indicated here, makes JPA querying useless in our case. So... we are forced to drop back to using native SQL.

This is a major defect and I am surprised it was not picked up by the functional testing when upgrading from 4.2.9 to 4.3.0. The effect of has the same severity as and can be seen as functional regression. Please address it as a matter of urgency.

Note: we've attempted using both JPA QL and Criteria API with the same results across 4.2.9 and 4.3.0+

Thimo Seitz

February 6, 2014, 5:56 PM

If i add the methods MapKeySource.getPathIdentifier() and MapKeyPath.render() from the commit "c421d7014b0a8b1270c34da01574837e9c4dbc36" the query seems to return the correct result.
It seems that the Fix for Bug affect also the 4.3 branch.