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