> > 14.6.9 If a variable or a field of a variable is included in the > > result, either directly or via navigation through the variable, > > then the semantics of the "contains" clause that include the > > variable change. In this case, all values of the variable that > > satisfy the filter are included in the result.
I don't see why the semantic changes here. The root change is the candidate result being the cartesian product of all variables projected Quoting [EMAIL PROTECTED]: > +1. Thanks for clearifying. > > I think the "exists" description is just misleading, since we only should > care > of computing the tuples and later filtering them one by one. > > Quoting Craig L Russell <[EMAIL PROTECTED]>: > > > Javadogs, > > > > For the purpose of clarifying this in the spec, I propose to add this > > to 14.6.9: > > > > <proposed> > > Result expressions begin with either an instance of the candidate > > class (with an explicit or implicit "this") or an instance of a > > variable (using the variable name). The candidate tuples are the > > cartesian product of the candidate class and all variables used in > > the result. The result tuples are the tuples of the candidate class > > and all variables used in the result that satisfy the filter. The > > result is the collection of result expressions projected from the > > result tuples. > > </proposed> > > > > Craig > > > > On Feb 6, 2006, at 12:34 PM, Craig Russell (JIRA) wrote: > > > > > [ http://issues.apache.org/jira/browse/JDO-246? > > > page=comments#action_12365343 ] > > > > > > Craig Russell commented on JDO-246: > > > ----------------------------------- > > > > > > The relevant parts of the specification are these: > > > > > > 14.6.5 A variable that is not constrained with an explicit contains > > > clause is constrained by the extent of the persistence capable > > > class (including subclasses). > > > ... > > > The semantics of contains is "exists", where the contains clause is > > > used to filter instances. The meaning of the expression > > > "emps.contains(e) && e.salary < param" is "there exists an e in the > > > emps collection such that e.salary is less than param". This is the > > > natural meaning of contains in the Java language, except where the > > > expression is negated. If the variable is used in the result, then > > > it need not be constrained. > > > ... > > > A portable query will constrain all variables with a contains > > > clause in each side of an "OR" expression of the filter where the > > > variable is used. Further, each variable must either be used in the > > > query result or its contains clause must be the left expression of > > > an "AND" expression where the variable is used in the right > > > expression. That is, for each occurrence of an expression in the > > > filter using the variable, there is a contains clause "ANDed" with > > > the expression that constrains the possible values by the elements > > > of a collection. > > > > > > 14.6.9 If a variable or a field of a variable is included in the > > > result, either directly or via navigation through the variable, > > > then the semantics of the "contains" clause that include the > > > variable change. In this case, all values of the variable that > > > satisfy the filter are included in the result. > > > ... > > > If any result is a navigational expression, and a non-terminal > > > field or variable has a null value for a particular set of > > > conditions (the result calculation would throw > > > NullPointerException), then the result is null for that result > > > expression. > > > > > > Using the sample query data provided in the TCK in > > > companyForQueryTests.xml and applying these to the cases at hand: > > > > > > SELECT this.name from org.apache.jdo.tck.pc.company.Department > > > WHERE name.matches(".*e.*") > > > > > > The candidate tuples are {dept1, dept2}. Both satisfy the > > > condition. The projection results in: > > > {"Development"}, {Human Resources"} > > > > > > SELECT this.name, e.lastname from > > > org.apache.jdo.tck.pc.company.Department WHERE name.matches > > > (".*e.*") VARIABLES Employee e > > > > > > This query is not portable because the variable employee is not > > > constrained. This is not so useful because the relationship between > > > department and employee is not constrained. Therefore the extent of > > > department and the extent of employee are used.The candidate tuples > > > are the cartesian product of {this, e}. There are two departments > > > and five employees, so the cartesian product contains 10 tuples. > > > The projection then is {{"Development", "emp1Last"}, > > > {"Development", "emp2Last"}, {"Development", "emp3Last"}, > > > {"Development", "emp4Last"}, {"Development", "emp5Last"}, {"Human > > > Resouces", "emp1Last"}, {"Human Resouces", "emp2Last"}, {"Human > > > Resouces", "emp3Last"}, {"Human Resouces", "emp4Last"}, {"Human > > > Resouces", "emp5Last"}}. > > > > > > SELECT this.name, e.lastname from > > > org.apache.jdo.tck.pc.company.Department WHERE name.matches > > > (".*e.*") && this.employees.contains(Employee e) > > > > > > The candidate tuples are the cartesian product of {this, e}. There > > > are two departments and five employees, so the cartesian product > > > contains 10 tuples. Of these 10, only 5 satisfy the filter because > > > of the emps.contains clause. These are {{dept1, emp1}, {dept1, > > > emp2}, {dept1, emp3}, {dept2, emp4}, {dept2, emp5}}. The projection > > > then is {{"Development", "emp1Last"}, {"Development", "emp2Last"}, > > > {"Development", "emp3Last"}, {"Human Resouces", "emp4Last"}, > > > {"Human Resouces", "emp5Last"}} > > > > > > SELECT employee.id, employee.manager.lastname FROM > > > org.apache.jdo.tck.pc.company.Department WHERE employees.contains > > > (employee) VARIABLES Employee employee > > > > > > The candidate tuples are this.employee. These are {{emp1}, {emp2}, > > > {emp3}, {emp4}, {emp5}}. The projection then is {{1", "emp2Last"}, > > > {2, "emp2Last"}, {3, "emp2Last"}, {4, null}, {5, null}} > > > > > > SELECT employee.manager.lastname FROM > > > org.apache.jdo.tck.pc.company.Department WHERE employees.contains > > > (employee) VARIABLES Employee employee > > > > > > The candidate tuples are this.employee. These are {{emp1}, {emp2}, > > > {emp3}, {emp4}, {emp5}}. The projection then is {{"emp2Last"}, > > > {"emp2Last"}, {"emp2Last"}, {null}, {null}} > > > > > > SELECT employee.lastname, project.name FROM > > > org.apache.jdo.tck.pc.company.Department VARIABLES Employee > > > employee; Project project > > > > > > This query is not portable because the variable employee is not > > > constrained. The candidate tuples are the cartesian product of > > > department, employee, and project. Two departments, five employees, > > > and three projects result in 30 tuples. The result will contain 30 > > > projections with each combination of employee.lastname and > > > project.name repeated twice (one for each department). > > > > > > SELECT employee.lastname, project.name FROM > > > org.apache.jdo.tck.pc.company.Department WHERE employees.contains > > > (Employee employee)VARIABLES Employee employee; Project project; > > > > > > This query is not portable because the variable project is not > > > constrained. The candidate tuples are the cartesian product of > > > department, employee, and project. Two departments, five employees, > > > and three projects result in 30 tuples. The filter reduces the > > > results to 15 (the cartesian product of the {department, employee- > > > who-works-in-the-department} and {project}. The result will contain > > > 15 projections with each combination of employee.lastname and > > > project.name. > > > > > > SELECT employee.lastname, project.name FROM > > > org.apache.jdo.tck.pc.company.Department WHERE employees.contains > > > (Employee employee) && employees.projects.contains(project) > > > VARIABLES Employee employee; Project project > > > > > > This query is portable because all variables are constrained. The > > > candidate tuples are the cartesian product of department, employee, > > > and project. Two departments, five employees, and three projects > > > result in 30 tuples. The filter reduces the result tuples to 7 > > > {{dept1, emp1, proj3}, {dept1, emp2, proj1}, {dept1, emp2, proj2}, > > > {dept1, emp3, proj1}, {dept1, emp3, proj2}, {dept2, emp4, proj3}, > > > {dept2, emp5, proj3}, }. The result will contain 7 projections > > > {{"emp1Last", "green"}, {"emp2Last", "orange"}, {"emp2Last", > > > "blue"}, {"emp3Last", "orange"}, {"emp3Last", "blue"}, {"emp4Last", > > > "green"}, {"emp5Last", "green"}} > > > > > > > > >> JPOX eliminates duplicates in the query result although DISTINCT > > >> is not specified. > > >> --------------------------------------------------------------------- > > >> ------------- > > >> > > >> Key: JDO-246 > > >> URL: http://issues.apache.org/jira/browse/JDO-246 > > >> Project: JDO > > >> Type: Bug > > >> Components: tck20 > > >> Versions: JDO 2 beta > > >> Reporter: Michael Watzek > > >> Assignee: Erik Bengtson > > >> Fix For: JDO 2 rc1 > > > > > >> > > >> Test case NPEInResultExpr fails because the result of the query > > >> below is expected to contain duplicates. JPOX eliminates the > > >> duplicates. > > >> 14:22:55,046 (main) DEBUG [org.apache.jdo.tck] - Executing API > > >> query: SELECT employee.manager.lastname FROM > > >> org.apache.jdo.tck.pc.company.Department WHERE employees.contains > > >> (employee) VARIABLES Employee employee > > >> 14:22:55,078 (main) DEBUG [org.apache.jdo.tck] - Query result: > > >> [emp2Last, null] > > >> 14:22:55,078 (main) DEBUG [org.apache.jdo.tck] - Wrong query result: > > >> expected: [emp2Last, null, emp2Last, emp2Last, emp2Last] > > >> got: [emp2Last, null] > > >> 14:22:55,078 (main) INFO [org.apache.jdo.tck] - Exception during > > >> setUp or runtest: > > >> junit.framework.AssertionFailedError: Assertion A14.6.9-4 > > >> (NPEInResultExpr) failed: > > >> Wrong query result: > > >> expected: [emp2Last, null, emp2Last, emp2Last, emp2Last] > > >> got: [emp2Last, null] > > >> at junit.framework.Assert.fail(Assert.java:47) > > >> at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546) > > >> at org.apache.jdo.tck.query.QueryTest.queryFailed(QueryTest.java: > > >> 500) > > >> at org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder > > >> (QueryTest.java:485) > > >> at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1189) > > >> at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) > > >> at org.apache.jdo.tck.query.QueryTest.executeAPIQuery > > >> (QueryTest.java:966) > > >> at org.apache.jdo.tck.query.QueryTest.executeAPIQuery > > >> (QueryTest.java:946) > > >> at org.apache.jdo.tck.query.result.NPEInResultExpr.testPositive > > >> (NPEInResultExpr.java:106) > > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > >> at sun.reflect.NativeMethodAccessorImpl.invoke > > >> (NativeMethodAccessorImpl.java:39) > > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke > > >> (DelegatingMethodAccessorImpl.java:25) > > >> at java.lang.reflect.Method.invoke(Method.java:324) > > >> at junit.framework.TestCase.runTest(TestCase.java:154) > > >> at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) > > >> at junit.framework.TestResult$1.protect(TestResult.java:106) > > >> at junit.framework.TestResult.runProtected(TestResult.java:124) > > >> at junit.framework.TestResult.run(TestResult.java:109) > > >> at junit.framework.TestCase.run(TestCase.java:118) > > >> at junit.framework.TestSuite.runTest(TestSuite.java:208) > > >> at junit.framework.TestSuite.run(TestSuite.java:203) > > >> at junit.framework.TestSuite.runTest(TestSuite.java:208) > > >> at junit.framework.TestSuite.run(TestSuite.java:203) > > >> at junit.textui.TestRunner.doRun(TestRunner.java:116) > > >> at junit.textui.TestRunner.doRun(TestRunner.java:109) > > >> at org.apache.jdo.tck.util.BatchTestRunner.start > > >> (BatchTestRunner.java:120) > > >> at org.apache.jdo.tck.util.BatchTestRunner.main > > >> (BatchTestRunner.java:95) > > > > > > -- > > > This message is automatically generated by JIRA. > > > - > > > If you think it was sent incorrectly contact one of the > > > administrators: > > > http://issues.apache.org/jira/secure/Administrators.jspa > > > - > > > For more information on JIRA, see: > > > http://www.atlassian.com/software/jira > > > > > > > Craig Russell > > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > > 408 276-5638 mailto:[EMAIL PROTECTED] > > P.S. A good JDO? O, Gasp! > > > > > > > >
