Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.

[Craig L Russell]

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:


Craig

On Feb 8, 2006, at 5:21 PM, Craig L Russell wrote:

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.]

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.

result being the cartesian product of all variables projected

I don't see why the semantic changes here. The root change is the candidate

Craig

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).

Quoting [EMAIL PROTECTED]:

+1. Thanks for clearifying.


care
of computing the tuples and later filtering them one by one.

Quoting Craig L Russell <[EMAIL PROTECTED]>:

I think the "exists" description is just misleading, since we only should

Javadogs,


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:

For the purpose of clarifying this in the spec, I propose to add this

    [ 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:


clause is constrained by the extent of the persistence capable
class (including subclasses).
...

used to filter instances. The meaning of the expression

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

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

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,

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

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

and three projects result in 30 tuples. The filter reduces the
results to 15 (the cartesian product of the {department, employee-

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

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",

"green"}, {"emp5Last", "green"}}

14.6.5 A variable that is not constrained with an explicit contains The semantics of contains is "exists", where the contains clause is "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 variable is used. Further, each variable must either be used in the 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 emp2}, {dept1, emp3}, {dept2, emp4}, {dept2, emp5}}. The projection department, employee, and project. Two departments, five employees, department, employee, and project. Two departments, five employees, who-works-in-the-department} and {project}. The result will contain candidate tuples are the cartesian product of department, employee, "blue"}, {"emp3Last", "orange"}, {"emp3Last", "blue"}, {"emp4Last",

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]

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)

500)

(QueryTest.java:485)

        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)

14:22:55,078 (main) DEBUG [org.apache.jdo.tck] - Wrong query result: at org.apache.jdo.tck.query.QueryTest.queryFailed (QueryTest.java: at org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java: 1189) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java: 1029)

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

smime.p7s
Description: S/MIME cryptographic signature