db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <Michelle.Cai...@Sun.COM>
Subject Re: Proposal for JIRA JDO-50
Date Wed, 15 Jun 2005 15:43:15 GMT
Excellent, thanks.

-- Michelle

Michael Watzek wrote:

> 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.
> Regards,
> Michael
>> 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

View raw message