Andrea Aime wrote: > 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...) Yeah its in FilterToSQL. > > 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 should note that I am seeing this is in the H2 module, and it is a select statement. >> 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. Ok.. at the moment it is getting passed a Long... so a number should fix it. I guess I need to track down where this is getting passed in from. I guess from the PropertyIs* methods which look at the type of the property and pass that as context. So will this be a special case of ensuring that when numeric values are being worked with the context should just be Number? > >> 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 ;) ) Wow... the next thing you are going to tell me is that hell is freezing over ;). > > It is good to encode 5.0 as 5 performance wise, but we cannot encode > 5.1 as 5, if you follow me. I do. > > Cheers > Andrea > > !DSPAM:4007,484fbcfa293607180515871! >
-- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
