+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! > >
