Hi Emily,

Emily Gouge wrote:
> Thanks for the info Justin.  (Sorry I'm slow getting back to you; I was 
> away last week).
> 
> If I work at implementing this can I bug you for help and ask you to 
> review the work as I go along?  I'm sure I'll need some advice on how to 
> do things properly.
Yeah for sure. Basically the general idea is this. The first part is 
easy, just add a public hint to the Converters class (or maybe 
ConvterFactory):

public static final Key SAFE_CONVERSION = new Key(Boolean.class);

Then the next step is hunt down every implementation of the Converter 
interface, and have it respect the SAFE_CONVERSION hint if it is set. 
Off the top of my head this mostly applies to the NumericConverter, and 
the TemporalConverter.

One hitch i notice is that while ConverterFactory.createConverter() 
takes a map of hints, Converter.convert() does not. So we probably have 
to add a method to the Converter interface.
> 
> Lastly - how do we define a "Safe Conversion"?  Is this something we can 
> define or is this well defined somewhere.  I'm thinking that converting 
> from integer to double is probably safe but not so for double to 
> integer.  I'm sure the other types have similar properties.
I guess any conversion that may result in any loss of information (a 
lossy conversion) would be considered unsafe? Perhaps someone has a more 
precise definition.
> 
> Thanks,
> Emily
> 
> 
> 
> Justin Deoliveira wrote:
>> Hi Emily and Jody,
>>
>> We have run up against this issue before, and it illuminates a pretty 
>> fundamental bug in our filter code. The following very basic test case 
>> for instance fails:
>>
>>  Literal d = ff.literal( 1.1 );
>>  Literal i = ff.literal( 1 );
>>
>>  Filter f1 = ff.greater( d, i );
>>  assertTrue( f1.evaluate( null ) );
>>
>>  Filter f2 = ff.less( i, d );
>>  assertTrue( f2.evaluate( null ) );
>>
>> When we ran up against this last time the plan (which we never 
>> implemented) was to have a way to specify that only "safe" conversions 
>> should be executed (via a hint). That way the logic in 
>> BinaryComparisonAbstract becomes:
>>
>> 1. try safe conversion from class1 to class 2
>> 2. try safe conversion from class2 to class 1
>> 3. fall back to current logic of unsafe conversions
>>
>> The converters api already supports hints, so all that is needed is to 
>> a) create the hint for safe conversions and b) to respect that hint in 
>> the NumericConverterFactory, and any other converter factories that 
>> potentially perform conversions that lose information.
>>
>> -Justin
>>
>> Jody Garnett wrote:
>>> On Wed, Jun 17, 2009 at 8:38 AM, Emily Gouge<ego...@refractions.net> 
>>> wrote:
>>>> Hmm I'm just not sure your extra code is needed.  There is already a
>>>> converter to convert from Strings to Numbers - what I really need is to
>>>> ensure that doubles are not converted to integers.
>>>
>>> That sounds good.
>>>
>>>> I wonder if we just need to call the convert function with Number 
>>>> instead of
>>>> double/integer etc.  This will convert strings if necessary.  I'm 
>>>> thinking
>>>> of this (passes all of the test cases you provided previously):
>>>>
>>>> Object o =  Converters.convert(v2, (v1 instanceof Number) ? 
>>>> Number.class
>>>> : v1.getClass());
>>>>
>>>> instead of
>>>>
>>>> Object o =  Converters.convert(v2, v1.getClass());
>>>
>>> Both those fail the test when:
>>> - v1 is a number and v2 is a string
>>> - both v1 or v2 are strings
>>>
>>> I think you need a two pass check
>>> 1. Check if you can convert the values to Number; if so do a comparison
>>> 2. Continue with normal comparison as per before (try and make them
>>> the same Compariable; and then compare)
>>>
>>> ------------------------------------------------------------------------------
>>>  
>>>
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing 
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Geotools-devel mailing list
>>> Geotools-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to