Implement new JDO 2 query tests cases concerning query API Extensions

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

Description

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

- A14.5-11: Construct a new query instance using the specified String as the single-string representation of the query.
- A14.5-12: Construct a new query instance with the given candidate class from a named query.
- A14.5-13: If the named query is not found in already-loaded metadata, the query is searched for using an algorithm. Files containing metadata are examined in turn until the query is found. The order is based on the metadata search order for class metadata, but includes files named based on the query name.
- A14.5-14: If the metadata is not found in the above, a JDOUserException is thrown.
- A14.5-15: The Query instance returned from this method can be modified by the application, just like any other Query instance.
- A14.5-16: Named queries must be compilable. Attempts to get a named query that cannot be compiled result in JDOUserException.
- A14.6-21: This method retrieves the fetch plan associated with the Query. It always returns the identical instance for the same Query instance. Any change made to the fetch plan affects subsequent query execution.
- A14.6-16: void setResult (String result); Specify the results of the query if not instances of the candidate class.
- A14.6-17: void setGrouping (String grouping); Specify the grouping of results for aggregates.
- A14.6-18: void setUnique (boolean unique); Specify that there is a single result of the query.
- A14.6-19: void setResultClass (Class resultClass); Specify the class to be used to return result instances.
- A14.6-20: setRange(int fromIncl, int toExcl); Specify the number of instances to skip over and the maximum number of result instances to return.
- A14.6-22: The Unmodifiable option, when set to true, disallows further modification of the query, except for specifying the range and result class and ignoreCache option.
- A14.6-23: The single string query is first parsed to yield the result, result class, filter, variable list, parameter list, import list, grouping, ordering, and range. Then, the values specified in APIs setResult, setResultClass, setFilter, declareVariables, declareParamters, declareImports, setGrouping, setOrdering, and setRange override the corresponding settings from the single string query.
- A14.9-1: Some JDO vendors provide extensions to the query, and these extensions must be set in the query instance prior to execution.

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

Comments

[Michael Watzek]

The attached patch implements the assertions above.

[Michael Bouschen]

A lot of new test cases. They look good, just a few comments:

QueryTest:
The new method takes an expected result and assumes an negative test if the expected result is null. This is ok, but it needs to be documented that we always pass an object array as expected result even in case of unique queries.

GetFetchPlan
Please adapt the javadoc of method checkFetchGroup2. You could that the method installs a new fetch group which loads a different field as the DFG. So jdoPostLoad will store different values into the transient fields which is then checked by the test case.

SingleStringQuery
I'm wondering about the values in the expectedResult array. The first entry represents the result of the first query being executes. The second entry represents the names of the Employee instances and not the employee instances itself. Do you need to convert the expected result (by calling method getCompanyModelInstances) before passing it to the second execute call?

NewNamedQuery:
Methods testPositive and testNegative seem to check the modifiable flag of the created query instances. Should this really be part of test NewNamedQuery, since class UnmodifiableQuery already covers this.

[Michael Watzek]

The second patch implements the comments above.

[Michael Bouschen]

The second patch looks good.

[Michael Watzek]

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

[Michael Watzek]

The third patch fixes 2 issues reported by Andy on jdo-dev:

1. MetadataSearchOrder.testPackageJDOQuery - this complains about not finding the
"jdoquery" file. By my understanding the jdoquery file is not being placed in the
"enhanced" directory, and hence JPOX would be working miracles to find it. Can
you check ?

2. SingleStringQuery.testPositive - this uses IMPORT in capitals. Should be lowercase

Additionally, the third patch fixes failing comparisons on object arrays. Moreover, it fixes toString() issues concerning object arrays.

A few comments about thr third patch (JDO-163.patch3):

Class QueryTest:
- Method equals(Object, Object) could check for identical instances first:
  if (o1 == o2) {
    result = true;
  } else ...
- In the last else if block we know o1 is null, so there is no need to call equals. I propose to replace the last else if block with
  } else {
    result = (o1 == o2);
  }
- How about adding javadoc for the new equalsXXX methods? I think it is important to note that the arguments passed to methods equalsObjectArray, equalsCollectione, qualsMap and contains must not be null.

Class SingleStringQuery:
- The patch removes the variable singleStringQuery, but the execute call a couple of lines later takes the variable as argument. The query as stored in singleStringQuery does not reflect the executed query, because the string defines a result.

ConversionHelper
- Method toUtilDate takes a Local instance which is not used, instead it uses Locale.US.
- I propose to rename convertsElementsOfTypeObjectArray to convertObjectArrayElements.
- I propose to replace method toCollection with Object[] convertObjectArrayElements(Object[]) and let the caller covert the returned Object[] into a collection.