JPOX returns wrong query result for non-extent queries.

• Key: JDO-241
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Erik Bengtson
• Reporter: Michael Watzek
• Component/s: tck2
• Affects Version/s: JDO 2 beta
• Fix Version/s: JDO 2 final

Description

Test case DistinctCandidateInstances fails because JPOX returns an empty collection for the query below. The query uses a candidate collection.

14:22:46,781 (main) DEBUG [org.apache.jdo.tck] - Executing JDO query: SELECT FROM org.apache.jdo.tck.pc.company.Person
14:22:46,796 (main) DEBUG [org.apache.jdo.tck] - Query result: []
14:22:46,812 (main) DEBUG [org.apache.jdo.tck] - Wrong query result:
expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone {work=123456-1, home=1111}, hired 1/Jan/1999, weeklyhours 40.0, $20000.0), FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone {work=123456-2, home=2222}, hired 1/Jul/2003, weeklyhours 40.0, $10000.0), PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone {work=123456-3, home=3333}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0), PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0), FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0), FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone {work=123456-1, home=1111}, hired 1/Jan/1999, weeklyhours 40.0, $20000.0), FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone {work=123456-2, home=2222}, hired 1/Jul/2003, weeklyhours 40.0, $10000.0), PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone {work=123456-3, home=3333}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0), PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0), FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
got: []
14:22:46,812 (main) INFO [org.apache.jdo.tck] - Exception during setUp or runtest:
junit.framework.AssertionFailedError: Assertion A14.6.9-2 (DistintCandidateInstances) failed:
Wrong query result:
expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone {work=123456-1, home=1111}, hired 1/Jan/1999, weeklyhours 40.0, $20000.0), FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone {work=123456-2, home=2222}, hired 1/Jul/2003, weeklyhours 40.0, $10000.0), PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone {work=123456-3, home=3333}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0), PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0), FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0), FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone {work=123456-1, home=1111}, hired 1/Jan/1999, weeklyhours 40.0, $20000.0), FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone {work=123456-2, home=2222}, hired 1/Jul/2003, weeklyhours 40.0, $10000.0), PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone {work=123456-3, home=3333}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0), PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0), FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
got: []
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.executeJDOQuery(QueryTest.java:1057)
at org.apache.jdo.tck.query.result.DistinctCandidateInstances.testCollectionQueries(DistinctCandidateInstances.java:129)
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)

Comments

If you look at the test you find that the "candidate collection" passed in is of transient instances which hence have no identity (or at least JDOHelper.getObjectId() returns null). You are expecting the JDO implementation to find these instances without allowing it to know their identities ? Hmmmm

To quote the spec [14.6] :
<spec>
For portability, the elements in the collection must be persistent instances associated with the same
PersistenceManager as the Query instance. An implementation might support transient instances in the collection.
</spec>

I notice that the second sentence here has a word "might". Hence the test cannot impose the restriction since its an optional feature.

[Michael Bouschen]

Attached you find a patch for review.

As Andy pointed out, support for queries over transient instances is optional. The patch changes the memory collection used as query candidates to include persistent instances. The test case still does not succeed, because JPOX seems to eliminate duplicates for a memory collection query with result specified as "this".

[Craig Russell]

The patch looks good.

[Michael Bouschen]

I checked in the patch (see revision 358033).

The test using a memory collection still fails, because the query does not return the expected result. The memory collection used as query candidates includes duplicates and since it is not a distinct query, the duplicates should be included in the query result.

[Andy Jefferson]

Hmmmm. You call setCandidates() and pass in the same object twice and so you expect the query to return dups ? Sounds unintuitive to me. The query specifies that some object is a candidate for being returned (twice) and that, to me at least, means that we allow the selected candidates be part of the result - and the object is part of the result. The basic query says return all Person objects. I see "candidates" as a further filter only ... not some way of saying "return me the same thing twice, or three times depending on how many times I put it in my candidates list".

[Craig Russell]

The spec is clear on this issue (which is specifically being tested). Queries against a collection return duplicates unless the distinct keyword is used.

<spec>
A14.6.9-2 [Queries against an extent always consider only distinct candidate instances, regardless of whether distinct is specified. Queries against a collection might contain duplicate candidate instances; the distinct keyword removes duplicates from the candidate collection in this case.]
</spec>

[Erik Bengtson]

fixed in JPOX cvs

[Craig Russell]

This is fixed in the latest JPOX SNAPSHOT.