Hi,
I like to propose a fix for JIRA JDO-50.
This issue suggests to add two floating point numbers to the TCK query
operator tests: 0.1 and -0.1. On the first glance, this change seems to
be trivial. However, it is not a trivial change. For this reason, I like
to discuss the fix beginning with a brief summery of the general
concept, and the implementation strategy of the query operator tests:
The general concept:
Class AllTypes maintains arrays for all supported types. The values in
these arrays represent an initial state of the database. There are query
tests for all JDOQL query operators. Each of these tests rely on the
initial database state. They perform queries on all supported types
checking the result against expected values.
The current implementation:
- The arrays of all supported types have a certain length (10).
- 10 objects of class AllTypes are made persistent. This is the initial
database state.
- Each quey test performs more or less 30 separate queries on each
supported type, and additionally the same amount of queries for wrapper
types. As a very rough estimation, there may be 2000-3000 separate
queries in the operators package.
- Each of these queries is passed a constant values as parameter and the
expected query result which depends on the certain array length (10).
The parameters must match values in the initial arrays of all supported
types.
Adding floating point values 0.1 and -0.1 to the implementation means:
- Increasing each of the initial arrays by two elements. Regardless, if
this makes sense or not (e.g. boolean arrays).
- Adapting the expected query result of all separate queries (about 2000
or 3000). This action has to be taken because the expected query result
depends on the certain array length (10).
- Adding new float and double queries for parameter values 0.1 and -0.1.
Obviously, this is a very big change for a very little functionality
enhancement. For this reason, I propose to change the implementation
strategy of the concept with the objective to make the implementation
independent from the initial database state. If we gained this
independency, we could extend the initial arrays without changing the
query operator tests.
The proposal:
In a first step, we try to reach independeny of the fixed array lengths.
Furthermore, we try to be independent of the constant values for query
parameters and the expected query results. After this step has been
taken, all arrays still have the same length (as now), but we do not
have 2000-3000 separate query calls in the code. Instead, we have loops
for each supported type in each query test. Inside each loop, we have
exactly one query call. The loops iterate over the elements of the
initial arrays. The parameter values are given by the current array
element. The expected query result can be derived by the current array
index.
The amount of query calls in the code will dramatically decrease. On the
other hand, we can be sure that all values of the initial arrays are
queried which is not the case today. This means that we gain
completeness for the query operator tests. Another advantage is the
extensibility of the implementation wrt. the initial arrays.
In a second step (which we can postpone to the future), we allow the
initial arrays to have different sizes. Thus, a boolean array would have
two elements (or three if we would have NULL tests).
I believe that the effort to implement the proposal does not exceed the
effort to add the floating points the the current implementation. It may
take about 4-5 days without step two.
Please let me know what you think.
Thanks,
Michael
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
|