Attendees: Michael Bouschen, Tilmann Zäschke, Craig Russell Agenda:
1. Experiments with queries and multiple navigations More test cases with navigation, need a new test class. AI Michael: file a new JIRA with proposed new test cases. Tilmann reports that get() applied to an Optional field can also return null and there are more test cases to test this behavior. In JDOQL, this.optional.get() is treated as this.optional. this.optional.isPresent() is treated as this.optional != null. Reconsidering the specification in light of issues with navigation through Optional or null-valued fields, we could make a small change to be more consistent with the treatment of null in SQL. SQL treats all arithmetic expressions with null as an operand as returning null; and boolean expressions with null as an operand specially: null & false-> false; null & true-> null; null | true-> true; null | false-> null. In JDOQL we also need to accommodate Optional..get() and Optional.isPresent() being mapped to null operations. In order to accommodate the semantic of navigation where part of the navigation path must be non-null, we can write: this.manager != null && this.manager.manager == null The above expression is true only for cases where the Employee has a manager but does not have a second-level manager. The similar expression this.manager.manager == null returns true for both Employee with no manager and Employee with manager but not second-level manager. Comparisons or arithmetic operations of null with any other type returns null, except for comparison with null using == null and != null, which always return true or false. The current specification: Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned false. Similarly, a failed cast operation, which would throw ClassCastException, is treated as if the subexpression returned false. Other subexpressions or [other values for variables might still qualify the candidate instance for inclusion in the result set.] Proposed specification: Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned null. Similarly, a failed cast operation, which would throw ClassCastException, is treated as if the subexpression returned null. Comparison of fields with null return null. Arithmetic expressions with null parameters return null. Optional.get() may return null. Optional.isPresent() is treated as !=null. Boolean expressions with null operands: true & null -> null false & null -> false true | null -> true false | null -> null 2. New patch on JDO-751 "Support for Java8 Optional" https://issues.apache.org/jira/browse/JDO-751 3. JDO-747 "Behavior of delete() with multiple concurrent Transactions" https://issues.apache.org/jira/browse/JDO-747 no news 4. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to prepare JCP Change Log no news 5. Other issues Action Items from weeks past: [Oct 30 2015] AI Craig: File a maintenance review with JCP [May 15 2015] AI Craig Spec change for roll back an active transaction when closing a persistence manager (JDO-735) [Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP Maintenance Release for JDO 3.1 is published [Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL datastores": https://issues.apache.org/jira/browse/JDO-651? [Feb 28 2014] AI Everyone: take a look at https://issues.apache.org/jira/browse/JDO-712 [Feb 28 2014] AI Everyone: take a look at https://issues.apache.org/jira/browse/JDO-625 [Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as persistent field types [Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about JDOHelper methods. In process. Craig L Russell Architect [email protected] P.S. A good JDO? O, Gasp!
