Thanks Craig. If a map is projected, do we have two cells (key, value) or one cell with type Map.Entry ?
I would expect it to be Map.Entry, what is in the spec? Quoting Craig L Russell <[EMAIL PROTECTED]>: > Javadogs, > > I've reworded the section in 14.6.9 as follows: > > removed: > 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. > > added: > A14.6.9-3 [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. If variables are not used in the result expression, > then the filter is evaluated for all possible values for each such > variable, and if the filter evaluates to true for any combination of > such variables, then the candidate tuple becomes a result tuple.] > > Craig > > On Feb 8, 2006, at 5:21 PM, Craig L Russell wrote: > > > Hi Erik, > > > > On Feb 8, 2006, at 1:41 PM, [EMAIL PROTECTED] wrote: > > > >>>> 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 > > > > I see your point. With the proposed clarification there is no > > change in semantics. > > > > Thanks for the good catch. I'll work on integrating these two > > (might just remove the paragraph above). > > > > Craig > >> > >> 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! > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > 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! > > > > 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! > >
