Jody Garnett ha scritto:
> Andrea Aime wrote:
>> * there is something strange going on in the filter encoders...
>> they do check if the filter is fully supported before proceeding,
>> but that in turn does not check whether the expressions inside the
>> filter are supported, leading to a situation where
>> one could break encoding by passing a supported filter that
>> uses an unsupported function. I've opened a jira for this:
>> http://jira.codehaus.org/browse/GEOT-1801
>>
> Thanks Andrea; I have had that problem in the back of my mind for a
> while (one of the motivations for tracking FilterCapabilities - and the
> function list) at the DataStore level).
>
> As for GEOT-1802 the "attrribute null '5' or "attribute + '5'" thing ...
> what are you trying to describe here? Is it literally...
> <Literal>attribute + 5</Literal>
> <ADD><PropertyName>attribute</PropertyName><Literal>5</Literal></ADD>
>
> What was the input that generated the encoder mistake?
No, I'm not using any parsing, the test code is:
Add a = filterFac.add(filterFac.property("testAttr"), filterFac.literal(5));
encoder.setFeatureType(integerFType);
encoder.encode(a);
assertEquals("testAttr + 5", output.toString());
and it fails with the SqlToFilter as is, the result is
"testAttr + '5'" instead, because the literal encoding
does not get a target class type, and thus it decides to take
whatever is in the literal and treat is as a string.
Which is silly imho.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
