Proposal for JIRA JDO-50

[Michael Watzek <mw...@spree.de>]

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/
-------------------------------------------------------------------

Re: Proposal for JIRA JDO-50

[Michelle Caisse <Mi...@Sun.COM>]

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
>>
>>
>>
>
>

Re: Proposal for JIRA JDO-50

[Michael Watzek <mw...@spree.de>]

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
> 
> 


-- 
-------------------------------------------------------------------
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/
-------------------------------------------------------------------

Re: Proposal for JIRA JDO-50

[Michelle Caisse <Mi...@Sun.COM>]

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