Andrea Aime wrote: > 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. Okay I understand; the problem is that the parsers now try and keep <Literal>5</Literal> as a "5" and put off deciding how to treat that until the very last moment (expressed by evaulate( obj, target )...
Looking at the code example for GEOT-1802 we probably can do a little bit better; right now we are throwing away the context information before writeLiteral(...) is called. That is a bit of a mistake right? We need to take that into account; we should be checking if target is Numeric or Boolean.... To answer your question: Why weren't we converting the number to the right class? We did not ask for it to be in the right class ... Two things: - Object literal = expression.getValue(); // is WRONG we need expression.evaulate( null, target ); - Can you check if the target was null? Jody ------------------------------------------------------------------------- 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
