db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: Proposal for JIRA JDO-50
Date Wed, 15 Jun 2005 15:34:21 GMT
Hi Michelle,

I created a new issue (JDO-71, Type: improvement, Priority: minor) and 
pasted the proposal into the description. I closed JDO-50 (Resolution: 
Won't Fix) and added a link to JDO-71.


> Hi Michael,
> I'm sorry that my initial response to your question about JDO-50 was 
> delayed in arriving on jdo-dev.  I will try to remember to include your 
> name on the two list in the future to make sure that you receive a 
> response asap.
> Anyway, as I said, this fix is probably unnecessary because existing 
> values in the double_values array cover the same functional case as is 
> proposed by this issue.  Also, at this point it is more worthwhile to 
> put our time into getting existing tests to run and writing tests for 
> JDO 2 functionality rather than improving the tck11 tests.  So I think 
> you should add your ideas as a comment to the issue in case we decide to 
> pursue it in the future and close it as "won't fix".  It's interesting 
> to know that this was not as easy as it looked.
> Thanks,
> Michelle
> Michael Watzek wrote:
>> 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/

View raw message