|
Home > Archive > Apache JDO Project > July 2005 > JIRA JDO-104
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Andy Jefferson 2005-07-27, 5:45 pm |
| In reference to the Collection/List/Set tests failing with errors such as :-
test(org.apache.jdo.tck.models.fieldtypes.TestArrayListCollections)javax.jdo.JDODataStoreException:
ERROR 22003: The resulting value is outside the range for the data type
DOUBLE.
The test is trying to use a Collection of doubles, and insert Java values of
Double.MAX_SIZE into a Derby DOUBLE column, which will always be touch and go
with rounding issues etc (and whether the RDBMS in question complains when
the value is just outside its range, which Derby does, but mysql doesn't).
I look at the TestFieldsOfDouble and see that the largest value used in that
test for a Double is AllTypes.DOUBLE_LARGEST = 9999999999999.9
Should we not be using the same values (whatever they are) in the
collection/list/set tests, so we have consistency ?
--
Andy
| |
| Craig Russell 2005-07-27, 5:45 pm |
| | |
| Michelle Caisse 2005-07-28, 5:45 pm |
| Hi,
I've attached a patch for this issue for your review. It replaces all
occurences of Double.MAX_VALUE, Double.MIN_VALUE, Float.MAX_VALUE, and
Float.MIN_VALUE with AllTypes.DOUBLE_LARGEST, AllTypes.DOUBLE_SMALLEST,
AllTypes.FLOAT_LARGEST, AllTypes.FLOAT_SMALLEST, respectively.
| |
| Andy Jefferson 2005-07-28, 5:45 pm |
| Hi Michelle,
> I've attached a patch for this issue for your review. It replaces all
> occurences of Double.MAX_VALUE, Double.MIN_VALUE, Float.MAX_VALUE, and
> Float.MIN_VALUE with AllTypes.DOUBLE_LARGEST, AllTypes.DOUBLE_SMALLEST,
> AllTypes.FLOAT_LARGEST, AllTypes.FLOAT_SMALLEST, respectively.
Beat me to it!
Looks good.
The only thing I was thinking of was having the sample values defined in a
helper class, and having the values being used by FieldsOfDouble,
FieldsOfFloat, FieldsOfInt, etc as well as by ArrayListCollections,
CollectionCollections, etc. The benefit of doing that would be that there
would then be a standard set of values for each type, and the field tests and
collection tests could use the same values - so if we need to change them to
support other sample values we only change it in one place, and both types of
tests pick them up. Maybe its not necessary, and you're more familiar with
how the TCK is structured so can decide for yourselves.
--
Andy
| |
| Craig Russell 2005-07-28, 5:45 pm |
| | |
| Michelle Caisse 2005-07-28, 5:45 pm |
| Hi Andy,
I think this is a good idea, but we don't have the time to do it right
now. If you feel like it you could file a JIRA for this as an
enhancement and somebody could consider it later.
-- Michelle
Andy Jefferson wrote:
>Hi Michelle,
>
>
>
>
>Beat me to it!
>
>Looks good.
>
>The only thing I was thinking of was having the sample values defined in a
>helper class, and having the values being used by FieldsOfDouble,
>FieldsOfFloat, FieldsOfInt, etc as well as by ArrayListCollections,
>CollectionCollections, etc. The benefit of doing that would be that there
>would then be a standard set of values for each type, and the field tests and
>collection tests could use the same values - so if we need to change them to
>support other sample values we only change it in one place, and both types of
>tests pick them up. Maybe its not necessary, and you're more familiar with
>how the TCK is structured so can decide for yourselves.
>
>
>
| |
| Craig Russell 2005-07-28, 5:45 pm |
| | |
| Andy Jefferson 2005-07-28, 5:45 pm |
| > I think this is a good idea, but we don't have the time to do it right
> now. If you feel like it you could file a JIRA for this as an
> enhancement and somebody could consider it later.
No. Just apply your patch and i'll be happy :-)
--
Andy
| |
| Michelle Caisse 2005-07-28, 5:45 pm |
| Done! Onward to the next one...
-- Michelle
Andy Jefferson wrote:
>
>No. Just apply your patch and i'll be happy :-)
>
>
>
|
|
|
|
|