You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by "Michael Watzek (JIRA)" <ji...@apache.org> on 2005/12/09 15:39:08 UTC
[jira] Created: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
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
Assigned to: 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12366032 ]
Craig Russell commented on JDO-246:
-----------------------------------
In case you don't want to bother applying the patch, here are the results with the JPOX jar file as of this morning PST:
doRuntck.jdori:
Overriding previous definition of reference to this.jdori.classpath
[java] RUN VariableInResult.testDistinctNoNavigation
[java] RUN VariableInResult.testNoNavigation FAILURE
[java] RUN VariableInResult.testDistinctNavigation
[java] RUN VariableInResult.testNavigation FAILURE
[java] Description: Special Test
[java] Time: 032
[java] There were 2 failures:
[java] 1) testNoNavigation(org.apache.jdo.tck.query.result.VariableInResult)junit.framework.AssertionFailedError: Assertion A14.6.9-3 (VariableInResult) failed:
[java] Wrong query result:
[java] expected: [Project(1, name orange, budget 2500000.99), Project(1, name orange, budget 2500000.99), Project(1, name orange, budget 2500000.99)]
[java] got: [Project(1, name orange, budget 2500000.99)]
[java] at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546)
[java] at org.apache.jdo.tck.query.QueryTest.queryFailed(QueryTest.java:500)
[java] at org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder(QueryTest.java:485)
[java] at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1191)
[java] at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1031)
[java] at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:968)
[java] at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:948)
[java] at org.apache.jdo.tck.query.result.VariableInResult.testNoNavigation(VariableInResult.java:147)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204)
[java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120)
[java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95)
[java] 2) testNavigation(org.apache.jdo.tck.query.result.VariableInResult)junit.framework.AssertionFailedError: Assertion A14.6.9-3 (VariableInResult) failed:
[java] Wrong query result:
[java] expected: [[1, orange], [1, orange], [1, orange]]
[java] got: [[1, orange]]
[java] at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546)
[java] at org.apache.jdo.tck.query.QueryTest.queryFailed(QueryTest.java:500)
[java] at org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder(QueryTest.java:485)
[java] at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1191)
[java] at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1031)
[java] at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:968)
[java] at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:948)
[java] at org.apache.jdo.tck.query.result.VariableInResult.testNavigation(VariableInResult.java:165)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204)
[java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120)
[java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95)
> 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
> Attachments: VariableInResult.patch
>
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Michael Bouschen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12366031 ]
Michael Bouschen commented on JDO-246:
--------------------------------------
The patch VariableInResult.patch looks good!
> 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
> Attachments: VariableInResult.patch
>
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12363567 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
There is just two departments persisted, so should return only two instances.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=all ]
Craig Russell updated JDO-246:
------------------------------
Attachment: VariableInResult.patch
Please review this patch. It adds two new test queries to the "variables in result" test case. One of the queries projects the variable p and the other projects p.id and p.name. The two extra test queries specify "distinct" for the results.
> 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
> Attachments: VariableInResult.patch
>
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12365214 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
I navigate through the jdo expert group mail archives and noticed hot discussions on the topic
See messages around these dates
2004 01 06
2004 01 08
2004 01 10
2004 01 20
2004 06 20
2004 07 21
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Michael Bouschen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364667 ]
Michael Bouschen commented on JDO-246:
--------------------------------------
Section "14.6.9 Specifying the Result of a Query (Projections, Aggregates)" explicitly defines a different behavior in case a variable is included in the result:
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 read the above query to return the manager's lastname of all the employees included in the employees collection of each department.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=all ]
Craig Russell updated JDO-246:
------------------------------
Fix Version: JDO 2 rc1
Version: JDO 2 beta
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12370441 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
should be fixed in JPOX CVS
> 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 final
> Attachments: VariableInResult.patch
>
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Michael Bouschen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364631 ]
Michael Bouschen commented on JDO-246:
--------------------------------------
Here is the JDOQL:
SELECT e.manager.lastname FROM org.apache.jdo.tck.pc.company.Department
WHERE employees.contains(e) VARIABLES Employee e
The query selects the variable that iterates the collection of employees of the two Departments. Unless distinct is specified, the query should return as many values as there are instances in the employees collections.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364705 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
To me this is intersection. See the below example
Employee1
Employee2
Employee3
Dept1.employess=Employee1
Dept1.employess=Employee3
Dept2.employess=Employee2
Intersection
Employee1 x Dept1.employess=Employee1
Employee3 x Dept1.employess=Employee3
Employee2 x Dept2.employess=Employee2
I don't like this sintax since it changes an obvious behaviour, IMO. I would prefer to write it as
SELECT intersect(employee,this.employees).manager.lastname FROM org.apache.jdo.tck.pc.company.Department VARIABLES Employee employee
Now it's up to up to clearify
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=all ]
Craig Russell updated JDO-246:
------------------------------
Fix Version: JDO 2 final
(was: JDO 2 rc1)
> 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 final
> Attachments: VariableInResult.patch
>
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Michael Bouschen (JIRA)" <ji...@apache.org>.
[ 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364692 ]
Craig Russell commented on JDO-246:
-----------------------------------
Michael interprets the specification as I had intended when I wrote it. I'm willing to clarify the specification if needed.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364660 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
I dont understand. You are querying Departments and iterating each element of it. The elements that will be in the result are the ones where the filter evaluates to true. Here the filter evaluates to true the two elements. Now the only thing remaining is for each element we navigate to return the result, so two instances only
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=all ]
Craig Russell resolved JDO-246:
-------------------------------
Resolution: Fixed
This issue is fixed in the latest JPOX SNAPSHOT.
> 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 final
> Attachments: VariableInResult.patch
>
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12365629 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
Thanks for the explanation.
> 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364734 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
I will do a small change in your example before expanding it.
------------------------
Employee = {"Employee1","Employee2","Employee3"}
Department = {"dept1","dept2","dept3"}
Department.employees = {{"Employee1","Employee3"},{"Employee2"},{"Employee1","Employee2"}}
SELECT employee.name, employee.manager.lastname FROM org.apache.jdo.tck.pc.company.Department WHERE employees.contains(employee) VARIABLES Employee employee
Here, the results should be:
{"Employee1", "emp2Last"}
{"Employee3", null}
{"Employee2", "emp2Last"}
{"Employee1", "emp2Last"}
{"Employee2", "emp2Last"}
Simply removing employee.id should not change the number of rows of the result. It should only change the number of columns returned by the query.
------------------------
Now we add:
Resource = {"Resource1","Resource2","Resource3"}
Department.resources = {{"Resource2"},{"Resource2","Resource3","Resource1"},{"Resource1","Resource2"}}
SELECT employee.name, employee.manager.lastname, resource.name FROM org.apache.jdo.tck.pc.company.Department WHERE employees.contains(employee) && resources.contains(resource) VARIABLES Employee employee, Resource resource
Here the results can vary depending how you expect employee and resource sets be joined
{"Employee1", "emp2Last", "Resource2"}
{"Employee3", null, null}
{"Employee2", "emp2Last","Resource2"}
{null,null,"Resource3"}
{null,null,"Resource1"}
{"Employee1", "emp2Last","Resource1"}
{"Employee2", "emp2Last","Resource2"}
What does && or || operators would mean here?
Any other thoughts?
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364818 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
> I'm a little confused about the term intersection. Just for my understanding: do you mean Cartesian product?
We are using intersection between Department.employees vs Employee, since we only retain
the employees that are on both sets.
Employee = {"Employee1","Employee2","Employee3"}
Department = {"dept1","dept2","dept3"}
Department.employees = {{"Employee1","Employee3"},{"Employee2"},{"Employee1","Employee2"}}
{"Employee1", "emp2Last"}
{"Employee3", null}
{"Employee2", "emp2Last"}
{"Employee1", "emp2Last"}
{"Employee2", "emp2Last"}
A cartesian product would result in return all employees from Employee set for each Department.
> 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 :-):
You are the JDOQL expert here ;).
Now the second example, The way I exemplified I was thinking in a kind of outer join from Employee vs Resource. Meaning returning a row if one of both has an element in the set.
{"Employee1", "emp2Last", "Resource2"}
{"Employee3", null, null}
{"Employee2", "emp2Last","Resource2"}
{null,null,"Resource3"}
{null,null,"Resource1"}
{"Employee1", "emp2Last","Resource1"}
{"Employee2", "emp2Last","Resource2"}
The way you did it is different, you take Employee vs Resource and calculates the Cartesian product.
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"}
>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.
You mean an inner join if &&, and outer join ||
> Does this make sense?
I don't know. :(
We have these steps to calculate
1. Set e =Department.employees (Intersect) Employee
2. Set r =Departments.resources (Intersect) Resource
3. Set result = d (Cartesian Product) (e (Cartesian Product) r) (your example)
or
3. Set result = d (Cartesian Product) (e (outer join) r) (my example)
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364722 ]
Craig Russell commented on JDO-246:
-----------------------------------
It might be easier to think about this if we add another projection to the SELECT:
SELECT employee.id, employee.manager.lastname FROM org.apache.jdo.tck.pc.company.Department WHERE employees.contains(employee) VARIABLES Employee employee
Here, the results should be:
{1, "emp2Last"}
{2, null}
{3, "emp2Last"}
{4, "emp2Last"}
{5, "emp2Last"}
Simply removing employee.id should not change the number of rows of the result. It should only change the number of columns returned by the query.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: distinct by owner? select distinct collectionField from SomeClass
Posted by Wes Biggs <we...@tralfamadore.com>.
OK by me, though I would prefer the language to be something more like
this is an area of non-portable (rather than forbidden) behavior. I.e.
no need for TCK test cases.
In reference to Bin Sun's question regarding the distinct keyword,
however, I don't think an implementation would need to check if the
Collections/Maps were .equal(); the spec doesn't say so explicitly, but
I assume that "distinct" applies to JDO identity, not Java equality, and
two Collections/Maps would only be nondistinct if they had multiple
owning objects (which is explicitly NOT mandated per 20.2).
Wes
Craig L Russell wrote:
> Hi Bin,
>
> I think it's confusing to project a collection or map in a query. The
> reason is that if there is a variable that derives from the same
> field as is being projected, the user might think that the field will
> be subject to the same constraints as the query, but this would be
> wrong.
>
> I'd rather we restrict projections of collection and map in queries.
> We can always add it later once we think more about whether it makes
> sense and has a strong justification.
>
> What can the user not do today if we restrict projection of
> collections and maps? If the user really wants to navigate to the
> collection or map field, then just project the instance and navigate
> to the fields of interest.
>
> Craig
>
> On Feb 13, 2006, at 6:27 PM, Bin Sun wrote:
>
>> Hi, all!
>>
>> Did anyone notice this?
>>
>> --- Bin Sun <su...@yahoo.com> wrote:
>>
>>> Hi!
>>>
>>> I have more concern about Collection and Map
>>> projection: is this query easy to implement?
>>>
>>> select distinct employees from Department where ...
>>>
>>> At least I don't know how a SQL datastore could
>>> compare the collections one another.
>>>
>>> So, maybe we should discribe more on Collection
>>> and Map projection, or simply specify that their
>>> distinction is the same as their owner objects,
>>> dispite whether they equal one another.
>>>
Negative VOTE Issue 159: Restrict projections to single-valued fields
Posted by Craig L Russell <Cr...@Sun.COM>.
Javadogs,
If none of the implementations supports projections of collections or
maps, we can simply disallow it. If some do support it, we can say
it's not portable.
For now, I'll propose disallowing it, and if there are
implementations out there we can change to non-portable.
<proposal 14.6.9>
Specifying the Result of a Query (Projections, Aggregates)
The application might want to get results from a query that are not
instances of the candidate class. The results might be single-valued
fields of persistent instances, instances of classes other than the
candidate class, or aggregates of single-valued fields.
</proposal 14.6.9>
Craig
On Feb 13, 2006, at 8:58 PM, Craig L Russell wrote:
> Hi Bin,
>
> I think it's confusing to project a collection or map in a query.
> The reason is that if there is a variable that derives from the
> same field as is being projected, the user might think that the
> field will be subject to the same constraints as the query, but
> this would be wrong.
>
> I'd rather we restrict projections of collection and map in
> queries. We can always add it later once we think more about
> whether it makes sense and has a strong justification.
>
> What can the user not do today if we restrict projection of
> collections and maps? If the user really wants to navigate to the
> collection or map field, then just project the instance and
> navigate to the fields of interest.
>
> Craig
>
> On Feb 13, 2006, at 6:27 PM, Bin Sun wrote:
>
>> Hi, all!
>>
>> Did anyone notice this?
>>
>> --- Bin Sun <su...@yahoo.com> wrote:
>>
>>> Hi!
>>>
>>> I have more concern about Collection and Map
>>> projection: is this query easy to implement?
>>>
>>> select distinct employees from Department where ...
>>>
>>> At least I don't know how a SQL datastore could
>>> compare the collections one another.
>>>
>>> So, maybe we should discribe more on Collection
>>> and Map projection, or simply specify that their
>>> distinction is the same as their owner objects,
>>> dispite whether they equal one another.
>>>
>>> --- erik@jpox.org wrote:
>>>
>>>> Thanks for the comments, I agree with you all.
>>>>
>>>> Regards,
>>>>
>>>> Quoting Michael Bouschen <mb...@spree.de>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have the same understanding of the semantics
>>> of
>>>> projections of
>>>>> collection and map fields as Wes and Bin Sun.
>>> The
>>>> query would return the
>>>>> collections or maps as single cells, so the
>>> query
>>>> result would be a list
>>>>> of collections or maps. I also agree that
>>> support
>>>> for projections of
>>>>> collection and map fields does not add much
>>> value,
>>>> but AFAIK the current
>>>>> spec allows this.
>>>>>
>>>>> I think the shape of the query result is
>>> different
>>>> whether projecting a
>>>>> collection field or including a variable in the
>>>> result that iterates the
>>>>> collection:
>>>>> (1) SELECT employees FROM Department
>>>>> (2) SELECT e FROM Department WHERE
>>>> employees.contains(e)
>>>>> The first query returns a list of collections of
>>>> employees, so for each
>>>>> department it returns the department's employee
>>>> collection. Query (2)
>>>>> returns a list of employees, where each returned
>>>> employee is included in
>>>>> an employee collection of at least one
>>>> department.
>>>>>
>>>>> Given the above is correct, JDOQL would never
>>>> return Map.Entry
>>>>> instances. Either the query projects the entire
>>>> map or it iterates the
>>>>> map using containsKey or containsValue, but
>>> there
>>>> is no contains for maps.
>>>>>
>>>>> Regards Michael
>>>>>
>>>>>> Hi, all!
>>>>>>
>>>>>> If I didn't miss anything in the spec, I
>>>> would
>>>>>> expect 'single-cell' result for a collection
>>> or
>>>> map
>>>>>> field, as if it is a simple field or reference
>>>> field.
>>>>>>
>>>>>> eg.
>>>>>>
>>>>>> "select employees from Department"
>>>>>> -->
>>>>>> [employees of Dept 1]
>>>>>> [employees of Dept 2]
>>>>>> [employees of Dept 3]
>>>>>> ...
>>>>>>
>>>>>> Assume Student.scores: Map<Course, Float>
>>>>>> "select name, scores from Student"
>>>>>> -->
>>>>>> aaa,[scores map for aaa]
>>>>>> bbb,[scores map for bbb]
>>>>>> ccc,[scores map for ccc]
>>>>>>
>>>>>>
>>>>>> --- erik@jpox.org wrote:
>>>>>>
>>>>>>
>>>>>>> Actually, you can project a collection field,
>>>> but in
>>>>>>> fact what is projected are
>>>>>>> the elements of the collection.
>>>>>>>
>>>>>>> dept = {"dept1","dept2"}
>>>>>>> dept1.employees = {"emp1","emp2","emp3"}
>>>>>>> dept2.employees = {"emp4","emp5"}
>>>>>>>
>>>>>>> "select employees from Department" will result
>>>> in
>>>>>>>
>>>>>>> emp1
>>>>>>> emp2
>>>>>>> emp3
>>>>>>> emp4
>>>>>>> emp5
>>>>>>>
>>>>>>> "select this, employees from Department" will
>>>> result
>>>>>>> in
>>>>>>>
>>>>>>> dept1, emp1
>>>>>>> dept1, emp2
>>>>>>> dept1, emp3
>>>>>>> dept2, emp4
>>>>>>> dept2, emp5
>>>>>>>
>>>>>>> I would like to know what would that be in
>>> case
>>>> of
>>>>>>> Map or arrays.
>>>>>>>
>>>>>>> Quoting Wes Biggs <we...@tralfamadore.com>:
>>>>>>>
>>>>>>>
>>>>>>>> It doesn't make much sense to me to project
>>> to
>>>> map
>>>>>>>
>>>>>>> or collection fields,
>>>>>>>
>>>>>>>> though I don't see it explicitly discussed in
>>>> the
>>>>>>>
>>>>>>> spec. I suppose if we
>>>>>>>
>>>>>>>> allowed it, the cell would be of type Map or
>>>>>>>
>>>>>>> Collection (or etc. as
>>>>>>>
>>>>>>>> declared). Or am I missing some kind of
>>>> automatic
>>>>>>>
>>>>>>> flattening function?
>>>>>>>
>>>>>>>> i.e., today can you do:
>>>>>>>> "select employees from Department" (returns
>>>> cells
>>>>>>>
>>>>>>> of type Collection)?
>>>>>>>
>>>>>>>> Perhaps I'm confusing the issue.
>>>>>>>>
>>>>>>>> Wes
>>>>>>>>
>>>>>>>> erik@jpox.org wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> __________________________________________________
>>>>>> Do You Yahoo!?
>>>>>> Tired of spam? Yahoo! Mail has the best spam
>>>> protection around
>>>>>> http://mail.yahoo.com
>>>>>
>>>
>> === message truncated ===
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>
> 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!
Re: distinct by owner? select distinct collectionField from SomeClass
Posted by Bin Sun <su...@yahoo.com>.
I agree to disallow projection of collection and map
fields.
I just saw Erik and Michael discussing this and
speak out my concern.
--- Craig L Russell <Cr...@Sun.COM> wrote:
> Hi Bin,
>
> I think it's confusing to project a collection or
> map in a query. The
> reason is that if there is a variable that derives
> from the same
> field as is being projected, the user might think
> that the field will
> be subject to the same constraints as the query, but
> this would be
> wrong.
>
> I'd rather we restrict projections of collection and
> map in queries.
> We can always add it later once we think more about
> whether it makes
> sense and has a strong justification.
>
> What can the user not do today if we restrict
> projection of
> collections and maps? If the user really wants to
> navigate to the
> collection or map field, then just project the
> instance and navigate
> to the fields of interest.
>
> Craig
>
> On Feb 13, 2006, at 6:27 PM, Bin Sun wrote:
>
> > Hi, all!
> >
> > Did anyone notice this?
> >
> > --- Bin Sun <su...@yahoo.com> wrote:
> >
> >> Hi!
> >>
> >> I have more concern about Collection and Map
> >> projection: is this query easy to implement?
> >>
> >> select distinct employees from Department where
> ...
> >>
> >> At least I don't know how a SQL datastore could
> >> compare the collections one another.
> >>
> >> So, maybe we should discribe more on
> Collection
> >> and Map projection, or simply specify that their
> >> distinction is the same as their owner objects,
> >> dispite whether they equal one another.
> >>
> >> --- erik@jpox.org wrote:
> >>
> >>> Thanks for the comments, I agree with you all.
> >>>
> >>> Regards,
> >>>
> >>> Quoting Michael Bouschen <mb...@spree.de>:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have the same understanding of the semantics
> >> of
> >>> projections of
> >>>> collection and map fields as Wes and Bin Sun.
> >> The
> >>> query would return the
> >>>> collections or maps as single cells, so the
> >> query
> >>> result would be a list
> >>>> of collections or maps. I also agree that
> >> support
> >>> for projections of
> >>>> collection and map fields does not add much
> >> value,
> >>> but AFAIK the current
> >>>> spec allows this.
> >>>>
> >>>> I think the shape of the query result is
> >> different
> >>> whether projecting a
> >>>> collection field or including a variable in the
> >>> result that iterates the
> >>>> collection:
> >>>> (1) SELECT employees FROM Department
> >>>> (2) SELECT e FROM Department WHERE
> >>> employees.contains(e)
> >>>> The first query returns a list of collections
> of
> >>> employees, so for each
> >>>> department it returns the department's employee
> >>> collection. Query (2)
> >>>> returns a list of employees, where each
> returned
> >>> employee is included in
> >>>> an employee collection of at least one
> >>> department.
> >>>>
> >>>> Given the above is correct, JDOQL would never
> >>> return Map.Entry
> >>>> instances. Either the query projects the entire
> >>> map or it iterates the
> >>>> map using containsKey or containsValue, but
> >> there
> >>> is no contains for maps.
> >>>>
> >>>> Regards Michael
> >>>>
> >>>>> Hi, all!
> >>>>>
> >>>>> If I didn't miss anything in the spec, I
> >>> would
> >>>>> expect 'single-cell' result for a collection
> >> or
> >>> map
> >>>>> field, as if it is a simple field or reference
> >>> field.
> >>>>>
> >>>>> eg.
> >>>>>
> >>>>> "select employees from Department"
> >>>>> -->
> >>>>> [employees of Dept 1]
> >>>>> [employees of Dept 2]
> >>>>> [employees of Dept 3]
> >>>>> ...
> >>>>>
> >>>>> Assume Student.scores: Map<Course, Float>
> >>>>> "select name, scores from Student"
> >>>>> -->
> >>>>> aaa,[scores map for aaa]
> >>>>> bbb,[scores map for bbb]
> >>>>> ccc,[scores map for ccc]
> >>>>>
> >>>>>
> >>>>> --- erik@jpox.org wrote:
> >>>>>
> >>>>>
> >>>>>> Actually, you can project a collection field,
> >>> but in
> >>>>>> fact what is projected are
> >>>>>> the elements of the collection.
> >>>>>>
> >>>>>> dept = {"dept1","dept2"}
> >>>>>> dept1.employees = {"emp1","emp2","emp3"}
> >>>>>> dept2.employees = {"emp4","emp5"}
> >>>>>>
> >>>>>> "select employees from Department" will
> result
> >>> in
> >>>>>>
> >>>>>> emp1
> >>>>>> emp2
> >>>>>> emp3
> >>>>>> emp4
> >>>>>> emp5
> >>>>>>
> >>>>>> "select this, employees from Department" will
> >>> result
> >>>>>> in
> >>>>>>
> >>>>>> dept1, emp1
> >>>>>> dept1, emp2
> >>>>>> dept1, emp3
> >>>>>> dept2, emp4
> >>>>>> dept2, emp5
> >>>>>>
> >>>>>> I would like to know what would that be in
> >> case
> >>> of
> >>>>>> Map or arrays.
> >>>>>>
> >>>>>> Quoting Wes Biggs <we...@tralfamadore.com>:
> >>>>>>
> >>>>>>
> >>>>>>> It doesn't make much sense to me to project
> >> to
> >>> map
> >>>>>>
> >>>>>> or collection fields,
> >>>>>>
> >>>>>>> though I don't see it explicitly discussed
> in
> >>> the
> >>>>>>
> >>>>>> spec. I suppose if we
> >>>>>>
> >>>>>>> allowed it, the cell would be of type Map or
> >>>>>>
> >>>>>> Collection (or etc. as
> >>>>>>
> >>>>>>> declared). Or am I missing some kind of
> >>> automatic
> >>>>>>
> >>>>>> flattening function?
> >>>>>>
> >>>>>>> i.e., today can you do:
> >>>>>>> "select employees from Department" (returns
> >>> cells
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: distinct by owner? select distinct collectionField from SomeClass
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Bin,
I think it's confusing to project a collection or map in a query. The
reason is that if there is a variable that derives from the same
field as is being projected, the user might think that the field will
be subject to the same constraints as the query, but this would be
wrong.
I'd rather we restrict projections of collection and map in queries.
We can always add it later once we think more about whether it makes
sense and has a strong justification.
What can the user not do today if we restrict projection of
collections and maps? If the user really wants to navigate to the
collection or map field, then just project the instance and navigate
to the fields of interest.
Craig
On Feb 13, 2006, at 6:27 PM, Bin Sun wrote:
> Hi, all!
>
> Did anyone notice this?
>
> --- Bin Sun <su...@yahoo.com> wrote:
>
>> Hi!
>>
>> I have more concern about Collection and Map
>> projection: is this query easy to implement?
>>
>> select distinct employees from Department where ...
>>
>> At least I don't know how a SQL datastore could
>> compare the collections one another.
>>
>> So, maybe we should discribe more on Collection
>> and Map projection, or simply specify that their
>> distinction is the same as their owner objects,
>> dispite whether they equal one another.
>>
>> --- erik@jpox.org wrote:
>>
>>> Thanks for the comments, I agree with you all.
>>>
>>> Regards,
>>>
>>> Quoting Michael Bouschen <mb...@spree.de>:
>>>
>>>> Hi,
>>>>
>>>> I have the same understanding of the semantics
>> of
>>> projections of
>>>> collection and map fields as Wes and Bin Sun.
>> The
>>> query would return the
>>>> collections or maps as single cells, so the
>> query
>>> result would be a list
>>>> of collections or maps. I also agree that
>> support
>>> for projections of
>>>> collection and map fields does not add much
>> value,
>>> but AFAIK the current
>>>> spec allows this.
>>>>
>>>> I think the shape of the query result is
>> different
>>> whether projecting a
>>>> collection field or including a variable in the
>>> result that iterates the
>>>> collection:
>>>> (1) SELECT employees FROM Department
>>>> (2) SELECT e FROM Department WHERE
>>> employees.contains(e)
>>>> The first query returns a list of collections of
>>> employees, so for each
>>>> department it returns the department's employee
>>> collection. Query (2)
>>>> returns a list of employees, where each returned
>>> employee is included in
>>>> an employee collection of at least one
>>> department.
>>>>
>>>> Given the above is correct, JDOQL would never
>>> return Map.Entry
>>>> instances. Either the query projects the entire
>>> map or it iterates the
>>>> map using containsKey or containsValue, but
>> there
>>> is no contains for maps.
>>>>
>>>> Regards Michael
>>>>
>>>>> Hi, all!
>>>>>
>>>>> If I didn't miss anything in the spec, I
>>> would
>>>>> expect 'single-cell' result for a collection
>> or
>>> map
>>>>> field, as if it is a simple field or reference
>>> field.
>>>>>
>>>>> eg.
>>>>>
>>>>> "select employees from Department"
>>>>> -->
>>>>> [employees of Dept 1]
>>>>> [employees of Dept 2]
>>>>> [employees of Dept 3]
>>>>> ...
>>>>>
>>>>> Assume Student.scores: Map<Course, Float>
>>>>> "select name, scores from Student"
>>>>> -->
>>>>> aaa,[scores map for aaa]
>>>>> bbb,[scores map for bbb]
>>>>> ccc,[scores map for ccc]
>>>>>
>>>>>
>>>>> --- erik@jpox.org wrote:
>>>>>
>>>>>
>>>>>> Actually, you can project a collection field,
>>> but in
>>>>>> fact what is projected are
>>>>>> the elements of the collection.
>>>>>>
>>>>>> dept = {"dept1","dept2"}
>>>>>> dept1.employees = {"emp1","emp2","emp3"}
>>>>>> dept2.employees = {"emp4","emp5"}
>>>>>>
>>>>>> "select employees from Department" will result
>>> in
>>>>>>
>>>>>> emp1
>>>>>> emp2
>>>>>> emp3
>>>>>> emp4
>>>>>> emp5
>>>>>>
>>>>>> "select this, employees from Department" will
>>> result
>>>>>> in
>>>>>>
>>>>>> dept1, emp1
>>>>>> dept1, emp2
>>>>>> dept1, emp3
>>>>>> dept2, emp4
>>>>>> dept2, emp5
>>>>>>
>>>>>> I would like to know what would that be in
>> case
>>> of
>>>>>> Map or arrays.
>>>>>>
>>>>>> Quoting Wes Biggs <we...@tralfamadore.com>:
>>>>>>
>>>>>>
>>>>>>> It doesn't make much sense to me to project
>> to
>>> map
>>>>>>
>>>>>> or collection fields,
>>>>>>
>>>>>>> though I don't see it explicitly discussed in
>>> the
>>>>>>
>>>>>> spec. I suppose if we
>>>>>>
>>>>>>> allowed it, the cell would be of type Map or
>>>>>>
>>>>>> Collection (or etc. as
>>>>>>
>>>>>>> declared). Or am I missing some kind of
>>> automatic
>>>>>>
>>>>>> flattening function?
>>>>>>
>>>>>>> i.e., today can you do:
>>>>>>> "select employees from Department" (returns
>>> cells
>>>>>>
>>>>>> of type Collection)?
>>>>>>
>>>>>>> Perhaps I'm confusing the issue.
>>>>>>>
>>>>>>> Wes
>>>>>>>
>>>>>>> erik@jpox.org wrote:
>>>>>>>
>>>>>>>
>>>>>>>> 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?
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>> __________________________________________________
>>>>> Do You Yahoo!?
>>>>> Tired of spam? Yahoo! Mail has the best spam
>>> protection around
>>>>> http://mail.yahoo.com
>>>>
>>
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
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!
distinct by owner? select distinct collectionField from SomeClass
Posted by Bin Sun <su...@yahoo.com>.
Hi, all!
Did anyone notice this?
--- Bin Sun <su...@yahoo.com> wrote:
> Hi!
>
> I have more concern about Collection and Map
> projection: is this query easy to implement?
>
> select distinct employees from Department where ...
>
> At least I don't know how a SQL datastore could
> compare the collections one another.
>
> So, maybe we should discribe more on Collection
> and Map projection, or simply specify that their
> distinction is the same as their owner objects,
> dispite whether they equal one another.
>
> --- erik@jpox.org wrote:
>
> > Thanks for the comments, I agree with you all.
> >
> > Regards,
> >
> > Quoting Michael Bouschen <mb...@spree.de>:
> >
> > > Hi,
> > >
> > > I have the same understanding of the semantics
> of
> > projections of
> > > collection and map fields as Wes and Bin Sun.
> The
> > query would return the
> > > collections or maps as single cells, so the
> query
> > result would be a list
> > > of collections or maps. I also agree that
> support
> > for projections of
> > > collection and map fields does not add much
> value,
> > but AFAIK the current
> > > spec allows this.
> > >
> > > I think the shape of the query result is
> different
> > whether projecting a
> > > collection field or including a variable in the
> > result that iterates the
> > > collection:
> > > (1) SELECT employees FROM Department
> > > (2) SELECT e FROM Department WHERE
> > employees.contains(e)
> > > The first query returns a list of collections of
> > employees, so for each
> > > department it returns the department's employee
> > collection. Query (2)
> > > returns a list of employees, where each returned
> > employee is included in
> > > an employee collection of at least one
> > department.
> > >
> > > Given the above is correct, JDOQL would never
> > return Map.Entry
> > > instances. Either the query projects the entire
> > map or it iterates the
> > > map using containsKey or containsValue, but
> there
> > is no contains for maps.
> > >
> > > Regards Michael
> > >
> > > > Hi, all!
> > > >
> > > > If I didn't miss anything in the spec, I
> > would
> > > > expect 'single-cell' result for a collection
> or
> > map
> > > > field, as if it is a simple field or reference
> > field.
> > > >
> > > > eg.
> > > >
> > > > "select employees from Department"
> > > > -->
> > > > [employees of Dept 1]
> > > > [employees of Dept 2]
> > > > [employees of Dept 3]
> > > > ...
> > > >
> > > > Assume Student.scores: Map<Course, Float>
> > > > "select name, scores from Student"
> > > > -->
> > > > aaa,[scores map for aaa]
> > > > bbb,[scores map for bbb]
> > > > ccc,[scores map for ccc]
> > > >
> > > >
> > > > --- erik@jpox.org wrote:
> > > >
> > > >
> > > >>Actually, you can project a collection field,
> > but in
> > > >>fact what is projected are
> > > >>the elements of the collection.
> > > >>
> > > >>dept = {"dept1","dept2"}
> > > >>dept1.employees = {"emp1","emp2","emp3"}
> > > >>dept2.employees = {"emp4","emp5"}
> > > >>
> > > >>"select employees from Department" will result
> > in
> > > >>
> > > >>emp1
> > > >>emp2
> > > >>emp3
> > > >>emp4
> > > >>emp5
> > > >>
> > > >>"select this, employees from Department" will
> > result
> > > >>in
> > > >>
> > > >>dept1, emp1
> > > >>dept1, emp2
> > > >>dept1, emp3
> > > >>dept2, emp4
> > > >>dept2, emp5
> > > >>
> > > >>I would like to know what would that be in
> case
> > of
> > > >>Map or arrays.
> > > >>
> > > >>Quoting Wes Biggs <we...@tralfamadore.com>:
> > > >>
> > > >>
> > > >>>It doesn't make much sense to me to project
> to
> > map
> > > >>
> > > >>or collection fields,
> > > >>
> > > >>>though I don't see it explicitly discussed in
> > the
> > > >>
> > > >>spec. I suppose if we
> > > >>
> > > >>>allowed it, the cell would be of type Map or
> > > >>
> > > >>Collection (or etc. as
> > > >>
> > > >>>declared). Or am I missing some kind of
> > automatic
> > > >>
> > > >>flattening function?
> > > >>
> > > >>>i.e., today can you do:
> > > >>>"select employees from Department" (returns
> > cells
> > > >>
> > > >>of type Collection)?
> > > >>
> > > >>>Perhaps I'm confusing the issue.
> > > >>>
> > > >>>Wes
> > > >>>
> > > >>>erik@jpox.org wrote:
> > > >>>
> > > >>>
> > > >>>>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?
> > > >>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > > > http://mail.yahoo.com
> > >
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Posted by Bin Sun <su...@yahoo.com>.
Hi!
I have more concern about Collection and Map
projection: is this query easy to implement?
select distinct employees from Department where ...
At least I don't know how a SQL datastore could
compare the collections one another.
So, maybe we should discribe more on Collection
and Map projection, or simply specify that their
distinction is the same as their owner objects,
dispite whether they equal one another.
--- erik@jpox.org wrote:
> Thanks for the comments, I agree with you all.
>
> Regards,
>
> Quoting Michael Bouschen <mb...@spree.de>:
>
> > Hi,
> >
> > I have the same understanding of the semantics of
> projections of
> > collection and map fields as Wes and Bin Sun. The
> query would return the
> > collections or maps as single cells, so the query
> result would be a list
> > of collections or maps. I also agree that support
> for projections of
> > collection and map fields does not add much value,
> but AFAIK the current
> > spec allows this.
> >
> > I think the shape of the query result is different
> whether projecting a
> > collection field or including a variable in the
> result that iterates the
> > collection:
> > (1) SELECT employees FROM Department
> > (2) SELECT e FROM Department WHERE
> employees.contains(e)
> > The first query returns a list of collections of
> employees, so for each
> > department it returns the department's employee
> collection. Query (2)
> > returns a list of employees, where each returned
> employee is included in
> > an employee collection of at least one
> department.
> >
> > Given the above is correct, JDOQL would never
> return Map.Entry
> > instances. Either the query projects the entire
> map or it iterates the
> > map using containsKey or containsValue, but there
> is no contains for maps.
> >
> > Regards Michael
> >
> > > Hi, all!
> > >
> > > If I didn't miss anything in the spec, I
> would
> > > expect 'single-cell' result for a collection or
> map
> > > field, as if it is a simple field or reference
> field.
> > >
> > > eg.
> > >
> > > "select employees from Department"
> > > -->
> > > [employees of Dept 1]
> > > [employees of Dept 2]
> > > [employees of Dept 3]
> > > ...
> > >
> > > Assume Student.scores: Map<Course, Float>
> > > "select name, scores from Student"
> > > -->
> > > aaa,[scores map for aaa]
> > > bbb,[scores map for bbb]
> > > ccc,[scores map for ccc]
> > >
> > >
> > > --- erik@jpox.org wrote:
> > >
> > >
> > >>Actually, you can project a collection field,
> but in
> > >>fact what is projected are
> > >>the elements of the collection.
> > >>
> > >>dept = {"dept1","dept2"}
> > >>dept1.employees = {"emp1","emp2","emp3"}
> > >>dept2.employees = {"emp4","emp5"}
> > >>
> > >>"select employees from Department" will result
> in
> > >>
> > >>emp1
> > >>emp2
> > >>emp3
> > >>emp4
> > >>emp5
> > >>
> > >>"select this, employees from Department" will
> result
> > >>in
> > >>
> > >>dept1, emp1
> > >>dept1, emp2
> > >>dept1, emp3
> > >>dept2, emp4
> > >>dept2, emp5
> > >>
> > >>I would like to know what would that be in case
> of
> > >>Map or arrays.
> > >>
> > >>Quoting Wes Biggs <we...@tralfamadore.com>:
> > >>
> > >>
> > >>>It doesn't make much sense to me to project to
> map
> > >>
> > >>or collection fields,
> > >>
> > >>>though I don't see it explicitly discussed in
> the
> > >>
> > >>spec. I suppose if we
> > >>
> > >>>allowed it, the cell would be of type Map or
> > >>
> > >>Collection (or etc. as
> > >>
> > >>>declared). Or am I missing some kind of
> automatic
> > >>
> > >>flattening function?
> > >>
> > >>>i.e., today can you do:
> > >>>"select employees from Department" (returns
> cells
> > >>
> > >>of type Collection)?
> > >>
> > >>>Perhaps I'm confusing the issue.
> > >>>
> > >>>Wes
> > >>>
> > >>>erik@jpox.org wrote:
> > >>>
> > >>>
> > >>>>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?
> > >>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > > http://mail.yahoo.com
> >
> >
> > --
> > Michael Bouschen Tech@Spree Engineering GmbH
> > mailto:mbo.tech@spree.de http://www.tech.spree.de/
> > Tel.:++49/30/235 520-33 Buelowstr. 66
> > Fax.:++49/30/2175 2012 D-10783 Berlin
> >
>
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Posted by er...@jpox.org.
Thanks for the comments, I agree with you all.
Regards,
Quoting Michael Bouschen <mb...@spree.de>:
> Hi,
>
> I have the same understanding of the semantics of projections of
> collection and map fields as Wes and Bin Sun. The query would return the
> collections or maps as single cells, so the query result would be a list
> of collections or maps. I also agree that support for projections of
> collection and map fields does not add much value, but AFAIK the current
> spec allows this.
>
> I think the shape of the query result is different whether projecting a
> collection field or including a variable in the result that iterates the
> collection:
> (1) SELECT employees FROM Department
> (2) SELECT e FROM Department WHERE employees.contains(e)
> The first query returns a list of collections of employees, so for each
> department it returns the department's employee collection. Query (2)
> returns a list of employees, where each returned employee is included in
> an employee collection of at least one department.
>
> Given the above is correct, JDOQL would never return Map.Entry
> instances. Either the query projects the entire map or it iterates the
> map using containsKey or containsValue, but there is no contains for maps.
>
> Regards Michael
>
> > Hi, all!
> >
> > If I didn't miss anything in the spec, I would
> > expect 'single-cell' result for a collection or map
> > field, as if it is a simple field or reference field.
> >
> > eg.
> >
> > "select employees from Department"
> > -->
> > [employees of Dept 1]
> > [employees of Dept 2]
> > [employees of Dept 3]
> > ...
> >
> > Assume Student.scores: Map<Course, Float>
> > "select name, scores from Student"
> > -->
> > aaa,[scores map for aaa]
> > bbb,[scores map for bbb]
> > ccc,[scores map for ccc]
> >
> >
> > --- erik@jpox.org wrote:
> >
> >
> >>Actually, you can project a collection field, but in
> >>fact what is projected are
> >>the elements of the collection.
> >>
> >>dept = {"dept1","dept2"}
> >>dept1.employees = {"emp1","emp2","emp3"}
> >>dept2.employees = {"emp4","emp5"}
> >>
> >>"select employees from Department" will result in
> >>
> >>emp1
> >>emp2
> >>emp3
> >>emp4
> >>emp5
> >>
> >>"select this, employees from Department" will result
> >>in
> >>
> >>dept1, emp1
> >>dept1, emp2
> >>dept1, emp3
> >>dept2, emp4
> >>dept2, emp5
> >>
> >>I would like to know what would that be in case of
> >>Map or arrays.
> >>
> >>Quoting Wes Biggs <we...@tralfamadore.com>:
> >>
> >>
> >>>It doesn't make much sense to me to project to map
> >>
> >>or collection fields,
> >>
> >>>though I don't see it explicitly discussed in the
> >>
> >>spec. I suppose if we
> >>
> >>>allowed it, the cell would be of type Map or
> >>
> >>Collection (or etc. as
> >>
> >>>declared). Or am I missing some kind of automatic
> >>
> >>flattening function?
> >>
> >>>i.e., today can you do:
> >>>"select employees from Department" (returns cells
> >>
> >>of type Collection)?
> >>
> >>>Perhaps I'm confusing the issue.
> >>>
> >>>Wes
> >>>
> >>>erik@jpox.org wrote:
> >>>
> >>>
> >>>>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?
> >>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the
query result although DISTINCT is not specified.
Posted by Michael Bouschen <mb...@spree.de>.
Hi,
I have the same understanding of the semantics of projections of
collection and map fields as Wes and Bin Sun. The query would return the
collections or maps as single cells, so the query result would be a list
of collections or maps. I also agree that support for projections of
collection and map fields does not add much value, but AFAIK the current
spec allows this.
I think the shape of the query result is different whether projecting a
collection field or including a variable in the result that iterates the
collection:
(1) SELECT employees FROM Department
(2) SELECT e FROM Department WHERE employees.contains(e)
The first query returns a list of collections of employees, so for each
department it returns the department's employee collection. Query (2)
returns a list of employees, where each returned employee is included in
an employee collection of at least one department.
Given the above is correct, JDOQL would never return Map.Entry
instances. Either the query projects the entire map or it iterates the
map using containsKey or containsValue, but there is no contains for maps.
Regards Michael
> Hi, all!
>
> If I didn't miss anything in the spec, I would
> expect 'single-cell' result for a collection or map
> field, as if it is a simple field or reference field.
>
> eg.
>
> "select employees from Department"
> -->
> [employees of Dept 1]
> [employees of Dept 2]
> [employees of Dept 3]
> ...
>
> Assume Student.scores: Map<Course, Float>
> "select name, scores from Student"
> -->
> aaa,[scores map for aaa]
> bbb,[scores map for bbb]
> ccc,[scores map for ccc]
>
>
> --- erik@jpox.org wrote:
>
>
>>Actually, you can project a collection field, but in
>>fact what is projected are
>>the elements of the collection.
>>
>>dept = {"dept1","dept2"}
>>dept1.employees = {"emp1","emp2","emp3"}
>>dept2.employees = {"emp4","emp5"}
>>
>>"select employees from Department" will result in
>>
>>emp1
>>emp2
>>emp3
>>emp4
>>emp5
>>
>>"select this, employees from Department" will result
>>in
>>
>>dept1, emp1
>>dept1, emp2
>>dept1, emp3
>>dept2, emp4
>>dept2, emp5
>>
>>I would like to know what would that be in case of
>>Map or arrays.
>>
>>Quoting Wes Biggs <we...@tralfamadore.com>:
>>
>>
>>>It doesn't make much sense to me to project to map
>>
>>or collection fields,
>>
>>>though I don't see it explicitly discussed in the
>>
>>spec. I suppose if we
>>
>>>allowed it, the cell would be of type Map or
>>
>>Collection (or etc. as
>>
>>>declared). Or am I missing some kind of automatic
>>
>>flattening function?
>>
>>>i.e., today can you do:
>>>"select employees from Department" (returns cells
>>
>>of type Collection)?
>>
>>>Perhaps I'm confusing the issue.
>>>
>>>Wes
>>>
>>>erik@jpox.org wrote:
>>>
>>>
>>>>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?
>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Posted by Bin Sun <su...@yahoo.com>.
Hi, all!
If I didn't miss anything in the spec, I would
expect 'single-cell' result for a collection or map
field, as if it is a simple field or reference field.
eg.
"select employees from Department"
-->
[employees of Dept 1]
[employees of Dept 2]
[employees of Dept 3]
...
Assume Student.scores: Map<Course, Float>
"select name, scores from Student"
-->
aaa,[scores map for aaa]
bbb,[scores map for bbb]
ccc,[scores map for ccc]
--- erik@jpox.org wrote:
> Actually, you can project a collection field, but in
> fact what is projected are
> the elements of the collection.
>
> dept = {"dept1","dept2"}
> dept1.employees = {"emp1","emp2","emp3"}
> dept2.employees = {"emp4","emp5"}
>
> "select employees from Department" will result in
>
> emp1
> emp2
> emp3
> emp4
> emp5
>
> "select this, employees from Department" will result
> in
>
> dept1, emp1
> dept1, emp2
> dept1, emp3
> dept2, emp4
> dept2, emp5
>
> I would like to know what would that be in case of
> Map or arrays.
>
> Quoting Wes Biggs <we...@tralfamadore.com>:
>
> > It doesn't make much sense to me to project to map
> or collection fields,
> > though I don't see it explicitly discussed in the
> spec. I suppose if we
> > allowed it, the cell would be of type Map or
> Collection (or etc. as
> > declared). Or am I missing some kind of automatic
> flattening function?
> >
> > i.e., today can you do:
> > "select employees from Department" (returns cells
> of type Collection)?
> >
> > Perhaps I'm confusing the issue.
> >
> > Wes
> >
> > erik@jpox.org wrote:
> >
> > >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?
> > >
> > >
> > >
> >
> >
>
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Posted by er...@jpox.org.
Actually, you can project a collection field, but in fact what is projected are
the elements of the collection.
dept = {"dept1","dept2"}
dept1.employees = {"emp1","emp2","emp3"}
dept2.employees = {"emp4","emp5"}
"select employees from Department" will result in
emp1
emp2
emp3
emp4
emp5
"select this, employees from Department" will result in
dept1, emp1
dept1, emp2
dept1, emp3
dept2, emp4
dept2, emp5
I would like to know what would that be in case of Map or arrays.
Quoting Wes Biggs <we...@tralfamadore.com>:
> It doesn't make much sense to me to project to map or collection fields,
> though I don't see it explicitly discussed in the spec. I suppose if we
> allowed it, the cell would be of type Map or Collection (or etc. as
> declared). Or am I missing some kind of automatic flattening function?
>
> i.e., today can you do:
> "select employees from Department" (returns cells of type Collection)?
>
> Perhaps I'm confusing the issue.
>
> Wes
>
> erik@jpox.org wrote:
>
> >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?
> >
> >
> >
>
>
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the
query result although DISTINCT is not specified.
Posted by Wes Biggs <we...@tralfamadore.com>.
It doesn't make much sense to me to project to map or collection fields,
though I don't see it explicitly discussed in the spec. I suppose if we
allowed it, the cell would be of type Map or Collection (or etc. as
declared). Or am I missing some kind of automatic flattening function?
i.e., today can you do:
"select employees from Department" (returns cells of type Collection)?
Perhaps I'm confusing the issue.
Wes
erik@jpox.org wrote:
>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?
>
>
>
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Posted by er...@jpox.org.
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 <Cr...@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 <Cr...@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!
>
>
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the
query result although DISTINCT is not specified.
Posted by Craig L Russell <Cr...@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 <Cr...@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!
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the
query result although DISTINCT is not specified.
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <Cr...@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!
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Posted by er...@jpox.org.
> > 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
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 <Cr...@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!
> >
> >
>
>
>
>
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the query result although DISTINCT is not specified.
Posted by er...@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 <Cr...@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!
>
>
Re: [jira] Commented: (JDO-246) JPOX eliminates duplicates in the
query result although DISTINCT is not specified.
Posted by Craig L Russell <Cr...@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!
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (JDO-246) JPOX eliminates duplicates in the query
result although DISTINCT is not specified.
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-246?page=comments#action_12364821 ]
Erik Bengtson commented on JDO-246:
-----------------------------------
small correction (forgive my non scientific syntax):
We have these steps to calculate
1. Set e =Department.employees (Intersect) Employee
2. Set r =Departments.resources (Intersect) Resource
3. Set result = d.instance (Cartesian Product) (e (Cartesian Product) r) (your example)
or
3. Set result = d.instance (Cartesian Product) (e (outer join) r) (my example)
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira