Implement new JDO 2 query tests cases concerning result handling.

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

Description

We need 14 new test classes, one for each of the following assertions:

- A14.6.9-1: If distinct is specified, the query result does not include any duplicates. If the result parameter specifies more than one result expression, duplicates are those with matching values for each result expression.
- 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.
- A14.6.9-3: 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.
- A14.6.9-4: 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.
- A14.6.9-5: The result expressions include: ... The result expression can be explicitly cast using the (cast) operator.
- A14.6.9-6: Count returns Long. Sum returns Long for integral types and the field's type for other Number types (BigDecimal, BigInteger, Float, and Double). Sum is invalid if applied to non-Number types. Avg, min, and max return the type of the expression.
- A14.6.9-7: If the returned value from a query specifying a result is null, this indicates that the expression specified as the result was null.
- A14.6.9-8: If not specified, the result defaults to distinct this as C.
- A14.6.10-1: When grouping is specified, each result expression must be one of: an expression contained in the grouping expression; or, an aggregate expression evaluated once per group. The query groups all elements where all expressions specified in setGrouping have the same values. The query result consists of one element per group.
- A14.6.10-2: When having is specified, the having expression consists of arithmetic and boolean expressions containing aggregate expressions.
- A14.6.11-1: When the value of the Unique flag is true, then the result of a query is a single value, with null used to indicate that none of the instances in the candidates satisfied the filter. If more than one instance satisfies the filter, and the range is not limited to one result, then execute throws a JDOUserException.
- A14.6.11-2: The default Unique setting is true for aggregate results without a grouping expression, and false otherwise.
- A14.6.12-1:The result class may be one of the java.lang classes Character, Boolea, Byte, Short, Integer, Long, Float, Double, String, or Object[]; or one of the java.math classes BigInteger or BigDecimal; or the java.util class Date; or the java.util interface Map; or one of the java.sql classes Date, Time, or Timestamp; or a user-defined class.
- A14.6.12-2: Table 6: Shape of Result (C is the candidate class).

Details can be found on Wiki page http://wiki.apache.org/jdo/QueryTests#ResultHandling.

Comments

[Michael Watzek]

The attached patch implements the assertions above.

[Michael Bouschen]

Looks good, just a few comments:

QueryTest, ConversionHelper:
- These changes are already checked in as part of patch JDO-163 and will not be changed by this patch, correct?

ResultClassRequirements:
- The constructor test query should not define a result class using an INTO clause?
- I like the idea of having comments in the INVALID_QUERIES explaining why the query is invalid. I propose to add "salary field is not assignment compatible" to query with index 3.
VariableInResult:
- The string "orange" in the expected result is not a bean name, correct?
- I propose to split the test method testPositive into two methods. Then the first test method needs to convert the expected by calling getCompanyModelInstances where the second test method takes the expected result as it is.

DefaultUnique:
- Today the unique setting in the QueryElementHolder determines whether to expect a unique query result or not. This does not work if we want to check the default handling for unique. I think we need to add an overloaded execute method in QueryTest that takes the unique flag instead of calculating it from the unique setting of the QueryElementHolder.

NoArgsConstructor:
- I was confused because the class NoArgsConstructor does not have a no-args constructor. How about MissingNoArgsConstructor?
- The toString method misses to include the value of the field l.

NoFieldsNoMethods:
- Please update the class javadoc.

DistintCandidateInstances:
- How about splitting method testPositive in two test methods: testExtentQueries and testCollectionQueries?
- I propose to put pc instances into the collection used as query candidate collection.
- The test should explicitly define a candidate class.

[Michael Watzek]

The second patch implements the comments above.

Furthermore, the patch implements the comments in JDO-216 concerning the expected result of JDO2 query test cases .

[Michael Bouschen]

The patch looks good. Class Unique has the comment talking about avoiding file I/O which we can remove.

[Michael Watzek]

The second patch has been checked in (Revision 345921).