Hi Andy, After looking into this a bit more, you are right. And so am I.
You are right: If the query has an OR condition where one part of the OR involves navigating through a relationship and an INNER JOIN is used, then the other part of the OR will not be evaluated. I am right: DataNucleus does not properly implement the JDOQL requirement A14.6.2-9 [Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned false.] You are right also: Navigating nullable relationships in JDOQL is very tricky (error prone) and resources are scarce to implement the proper behavior in all situations. Craig > On Aug 2, 2016, at 3:23 AM, Andy Jefferson <a...@datanucleus.org> wrote: > >> Can you give a specific example where INNER JOIN would give the wrong answer? > There are likely many examples over the 8 years that this query generation > mechanism has been in place; all defaults have been set based on what was > needed to get a reliable mechanism for the vast majority of queries (and to > cater for JDOQL and JPQL). I don't have time to go back through old history > and work out some. > > What you can do is get the latest SNAPSHOT of "datanucleus-rdbms" and specify > the persistence property > "datanucleus.query.jdoql.navigationJoinTypeForFilter" as INNERJOIN (rather > than the current default of working it out based on the NULLability of the > field). This only applies to the FILTER of the query, so the SELECT clause > will use the current default still. You can then run the TCK like that and > see the effect. > > > One I did see was a failure on org.apache.jdo.tck.query.jdoql.IfElseInFilter > testPositive (which passes with current default join type strategy). This > query has JDOQL of the form > SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE (IF (this.manager == > null) this.mentor.department.deptid ELSE this.manager.department.deptid) == > this.department.deptid ORDER BY this.personid > > so likely the "IF THEN ELSE" expression in that example causing the > difference. > > > > Anyone who wants to pursue this can look at the following classes > > The JDOQL query itself, look for method "compileQueryFull" > https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/query/JDOQLQuery.java > > which then uses QueryToSQLMapper to convert the JDOQL compilation into an SQL > query > https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/query/QueryToSQLMapper.java > > And then kindly provide a Pull Request on GitHub that works for all > situations. > > > > > > > Regards > -- > Andy > DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus) Craig L Russell Architect craig.russ...@oracle.com P.S. A good JDO? O, Gasp!
