Result handling in class QueryTest must be capable to consider return types of java.lang.Object

• Key: JDO-216
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Michael Watzek
• Reporter: Michael Watzek
• Component/s: tck2

Description

The current result handling in class QueryTest cannot consider return types of type java.lang.Object. Unique queries and queries using aggregates in the select expression (single exression, no group by) return objects rather than collections. The result handling must reflect this fact. As a consequence, the expected result in query test cases must be capable to consider a single object also.

Currently, the expected result is declared as an object array in JDO2 query test classes. Method QueryTest.execute takes an object array as the expected result and an additional flag (unique) indicating if the query returns a single result. The unqiue parameter is calculated by methods in QueryTest executing query element holders. This is inadequate because the query element holder does not encapsulate the information of aggregates in single result expressions.

We propose to adapt the signature and the implementation of method QueryTest.execute: The expected result should be of type java.lang.Object and the unique parameter should be removed. Thus, the unique information can be calculated inside the method.

JDO2 query test classes in package query.api call method QueryTest.execute directly. These test cases must be adapted wrt the expected result: The expected result must be of the exact type which the query returns at runtime.

Other test cases which do not call method QueryTest.execute directly may be adapted wrt the expected result as part of a separate issue.

Comments

The attached patch implements the comments above.

[Michael Bouschen]

Look s good, just a few comments:

QueryTest
- Methods getCompanyModelInstances and getMylibInstances are deprecated, but we might need it to convert an array of beaan names in case actual parameters.
- Please add a comment why method checkQueryResultWithoutOrder cannot simply call equals(result, expected).
- Please add a comment why equalsCollection and equalsList cannot call o1.equals(o2). I think this is because the collections might include arrays which need to be compared using equalsObjectArray.
- I think method equalsMap needs to iterate the entry set and compare key and value for each entry. Comparing the set of keys and the set of values of the two maps fails in case two keys have the reveresed values.

SetGrouping and other
- Field expectedResult has commont talking about avoiding file IO at class loading time. This is true in case the expected result includes pc instacnes which is not the case here. I propose to remove the comment.

[Michael Watzek]

The attached patch has been checked in including the comments above (Revisiov 345514).