Re: [eclipselink-users] How to get the "mappedBy" attribute name of a re

[Mauro Molinari <mauromol@xxxxxxxxxx>]

Hi Chris!

Il 14/01/2016 21:02, christopher delahunt ha scritto:

First.second is a path _expression_, and the definition states "navigability is composed using “inner join” semantics".  The statement you site is meant as example showing what this means, but it did not attempt to explain what it means when the terminal side is null and having to differentiate entities from scalar fields.   Much of this discussion already occurred with bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=246211

I see, thanks for the pointer. Honestly, I'm not convinced by the choice made by EclipseLink, I think it's completely counter-intuitive, anyway I respect it. I just don't understand how you reconcile this with the statement that "JPA spec leader Linda DeMichiel confirmed that" that bug was valid.

I'm still convinced that the actual result when using "WHERE First.second IS NULL" should not differ if the mapping says that First owns the relationship or if it says that Second owns it. It's incoherent.

I agree, and I am not stating that they should differ.  What I'm stating is that the optimized behavior you are seeing so that it sometimes gives you the desired results is actually against what the specification states should happen.  Using "WHERE First.second IS NULL" should never be true according to the specification, as nulls are filtered out through an inner join.  EclipseLink chose to implement an optimization on some mappings that do not require a join but did not bother dealing with the inconsistencies of this edge case as this edge case really is disallowed by the specification - the JPA compliant way to write the query to get the results you want is to force a left outer join in the query.  

However, with this you're saying that:

• EclipseLink does not comply with the specification, because the "optimization" it applies (when the relationship is owned by First) actually makes the query bring wrong results
• I really think that if you ever decide to remove the optimization, to better adhere to the specification (at least under your interpretation), many JPQL queries around the world will miserably break, because I really can't imagine how anybody may interpret "SELECT first FROM First first WHERE first.second IS NULL" in a way that differs from "give me all the First entity instances with no Second related entity"; forcing the use of an outer join to express this basic condition sounds overwhelming to me

If we admit that this aspect of the specification leaves room for interpretation (as you wrote in the other bug report), then I would personally tend to prefer the most natural and reasonable one. And also taking a look to what other implementation do (although they are not the "reference" ones) may be a good approach. (honestly, I didn't try)

I am not involved in the specification so it is better if you forward your request/report directly. 

Thank you! I opened: https://java.net/jira/browse/JPA_SPEC-127

-- 

Mauro Molinari
E-mail: mauromol@xxxxxxxxxx