Justin Deoliveira ha scritto: > Hi all, > > While running wfs 1.1 cite tests on trunk I ran into the following > issue. Consider the filter: > > <ogc:Filter> > <ogc:PropertyIsEqualTo> > <ogc:PropertyName>sf:intProperty</ogc:PropertyName> > <ogc:Add> > <ogc:PropertyName>sf:decimalProperty</ogc:PropertyName> > <ogc:Literal>149.97</ogc:Literal> > </ogc:Add> > </ogc:PropertyIsEqualTo> > </ogc:Filter> > > When encoded as a predicate in sql: > > WHERE "intProperty" = "decimalProperty" + 149 > > Now... the reason this occurs is because the literal 149.97 is evaluated > in the context of an integer and is truncated.
Where is the code that is doing that? SqlEncoder? I believe the encoding code was modified so that the "best guess" from the string was used instead of the context which, as you say, cannot be really trusted to be a "rule" to follow.... oh but that was done only in FilterToSql, not in SqlEncoder (see http://jira.codehaus.org/browse/geot-1802... and I don't remember why I did fix FilterToSql instead of SqlEncoder...) Is the above a insert/update/delete or a select? The code path in PostgisDataStore is different for the two at the moment, the code that does write is using prepared statements, the one that does reads is still not. > I can think of a couple of solutions: > > 1. When encoding a binary expression like "Add" checking for the case of > a literal being added to a property. And instead of using the context > passed in while encoding the literal part, use the type of property > operand. Imho we should pass the encoder function just a Number.class context, that is, let it know we're doing math and not strings operations, but let it figure out the best holding type automatically. > 2. Ignore the context when encoding an Add and just encode everything > "raw" letting the database do the conversions. > > However there is one problem, in both cases the "solution" kills the use > of an index on the column being compared to. So... two more choices: > > 1. Leave things as is and ignore the crazy people that want to do this. > > 2. Implement the solution and tell people that if they do this they risk > a performance hit. I believe encoding sql corresponding to the filter is more important than speed (yes, correctness is more important than speed, even for me... but I want both to consider something worthwhile using ;) ) It is good to encode 5.0 as 5 performance wise, but we cannot encode 5.1 as 5, if you follow me. Cheers Andrea ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
