Hi,
I've recently stumbled into a fun problem with our sql encoding.
Say you have the following filter (which, while odd, is legal):
not(attribute > 3)
our sql translator translates it to:
not(attribute > 3)
Ahh.. all good no? No! The behavior of our in memory filtering, and
database filtering,
is not the same when "attribute" own value is null, for us null > 3 is
false, hence
not(null > 3) is true.
However, the databases work differently, any logic predicate handling a
null will return false,
no matter how complex it is, the difference is that we use two valued
logic, whilst databases
use three valued one: http://en.wikipedia.org/wiki/Three-valued_logic
Soo.. the correct SQL translation of the above filter would be:
not(attribute > 3) or attribute is null
or probably easier to encode:
not(attribute is not null and attribute > 3)
(that is, every time we do a binary comparison with an attribute, we add a
"att is not null" in the
predicate)
Anyone has better ideas? :-)
We could also have a look at the attribute metadata and see if the column
is nullable, or not.
Cheers
Andrea
--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel