db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Bouschen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Date Wed, 01 Feb 2006 15:12:41 GMT
    [ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364812 ] 

Michael Bouschen commented on JDO-246:

I'm a little confused about the term intersection. Just for my understanding: do you mean
Cartesian product?

Here is my understanding of the semantics of your query including the resource variable. Please
note, this does not necessarily mean it needs to be implemented that way :-):
The query first calculates the Cartesian product for Department, Employee and Resource: Department
x Employee  x Resources. This results in a set of triples. It then retains only those triples
where the employee *and* the resource have a relationship to the department in the first column
of the triple. The Select clause then defines values that are really returned by the query:
employee.name, employee.manager.lastname, resource.name. So the departments are not included
in the result.

Then the query result would be:
{"Employee1", "emp2Last", "Resource2"}
{"Employee3", null, "Resource2"}
{"Employee2", "emp2Last","Resource2"}
{"Employee2", "emp2Last","Resource3"}
{"Employee2", "emp2Last","Resource1"}
{"Employee1", "emp2Last","Resource1"}
{"Employee1", "emp2Last","Resource2"}
{"Employee2", "emp2Last","Resource1"}
{"Employee2", "emp2Last","Resource2"}
Rows 1 and 2 represent values for department dept1, rows 3-5 for dept2 and rows 6-9 for dept3.

About the difference between uisng && or ||:
I think with && only those tripels are retained where both the employee and the resource
have a relationship to the department of the triple. Using || the set of retained tripels
before the projection is bigger, because it also includes tripels where only one of the two
(employee, resource) is related to the department. 

Does this make sense?

> 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
>     Reporter: Michael Watzek
>     Assignee: Erik Bengtson

> 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:
For more information on JIRA, see:

View raw message