Justin Deoliveira wrote:
> 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
>
nasty! So we almost need two rounds of "type normalization"...
If we treat "Add" as a separate negotiation; expression1 is the only one
with a nice strong type ..
<ogc:Add>
<ogc:PropertyName>sf:decimalProperty</ogc:PropertyName>
<ogc:Literal>149.97</ogc:Literal>
</ogc:Add>
So this could end up adding two doubles ... resulting in a double
Then the propertyEquals check can do its own attempt a negotiate between
a intProperty and double; and end up comparing two ints...
> 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.
>
Yeah; that is my though; so we take the type of either expression1 or
expression2 (if either is a Propertyname); and handle the conversion
from the answer to the target type as a seperate step?
> 2. Ignore the context when encoding an Add and just encode everything "raw"
> letting the database do the conversions.
>
That is an option; encoding into SQL take the context into account if it
helps (say for Timestamp) and ignore in cases where it does not like Add.
> However there is one problem, in both cases the "solution" kills the use of
> an index on the column being compared to.
Does SQL have a function to "cast" a value into a known type?
> 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...
>
CITE has a test for this?
> Thoughts? On the bright side this was the only cite failure on trunk :).
>
That is great news - well done.
So this failure amounts to us being smarter than average bear. Or at
least us over thinking the problem ... do we have the option of telling
them the CITE test is bad? Or are we just trying to be wrong faster...
Jody
-------------------------------------------------------------------------
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
