Justin Deoliveira ha scritto:
...
>>> 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?
Hum, imho we should pass Number.class as the context in all cases where
we know a number is needed, so in Add, Divide, Multiply, Subtract,
should you ever be able to reach them without going thru PropertyIs*
(function arguments for example, not sure there are other cases).
A more centralized solution would be to treat numbers in a special
way in visit(Literal) and have the expression just figure out the best
representation for the number at hand?
This would be accomplished by simply adding an extra check before
trying to make the conversion:
if(target != null && !Number.isAssignableFrom(target))
literal = expression.evaluate(null, target);
An even better solution would be to change the converters so that
they do not try to coax 5.1 into 5, that is, allow the conversion
only when it's clean, and return null instead (in this case the
Which is something we already discussed in gt2-devel I believe, but I
can't find the thread anymore.
The forced casting that turns 149.97 into 149 is in
NumericConverterFactory btw.
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
