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 Wed, 08 Feb 2006 20:51:14 GMT
+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!
>
>




Mime
View raw message