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.

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.

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 will note that 1. will leave us non cite compliant...

Thoughts? On the bright side this was the only cite failure on trunk :).

-- 
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

Reply via email to