db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From e...@jpox.org
Subject Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Date Thu, 09 Feb 2006 15:40:02 GMT
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 <Craig.Russell@Sun.COM>:

> 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, erik@jpox.org 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 erik@jpox.org:
> >>
> >>> +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 <Craig.Russell@Sun.COM>:
> >>>
> >>>> 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:Craig.Russell@sun.com
> >>>> P.S. A good JDO? O, Gasp!
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>




Mime
View raw message