Hey all,
I think there may be a serious problem with the FilterCapabilities.ALL
and FilterCapabilities.NONE implementation on the trunk and 2.2.x
branch. I could be way off here though...so some feedback would be great.
As I understand it, a FilterCapabilities object represents the different
sorts of filters that a given SQLEncoder can unpack. So, for example,
if a datastore can't do spatial bbox queries, then its sqlencoder would
not include the SPATIAL_BBOX flag in its filterCapabilities.
This whole she-bang is implemented as a bitmask. From lines 53 down to
about 157, a whole list of different operators are defined, and then
assigned to a bit (via the left-shift operator). So, for example, the
following 32-bit binary number:
00000000000000000000000000000001
represents a filterCapabilities that supports SPATIAL_BBOX and nothing else.
Similarly, the following 32-bit number:
00000000000000000001000000000001
represents a filterCapabilities that supports SPATIAL_BBOX and LIKE, and
nothing else. etc.
The problem is that ALL and NONE are implemented as integers, and their
binary representations clobber the actual intended filter capabilities
for the capabilities objects to which they're added.
Check out this exmample:
FilterCapabilities f = new FilterCapabilities();
f.addType(FilterCapabilities.NONE);
This does the following (in the addType() method):
ops = ops | type;
i.e.
ops = 12345 | type;
i.e. (by converting 12345 to binary)
ops = 11000000111001 | type;
In the end, calling f.addType(FilterCapabilities.NONE) creates a filter
which claims to support:
* SPATIAL_BBOX (0x01)
* SPATIAL_INTERSECT (0x01<<3)
* SPATIAL_TOUCHES (0x01<<4)
* SPATIAL_CROSSES (0x01<<5)
* BETWEEN (0x01<<12)
* CHECK (0x01<<13)
I confirmed this with a unit test.
FilterCapabilities.ALL probably does something even more wacky, because
Java probably stores negative longs as two's-compliments in binary.
All of this is to say, that ALL and NONE are actually different flags
that need to be added to the list of bit-shifted flags.
Does any of this make sense? I've attached a FilterCapabiilities patch
that fixes the trunk, and can do so for 2.2.x as well if needed.
--saul
Index: /home/ENV/sfarber/dev/geotools/geotools-trunk/module/main/src/org/geotools/filter/FilterCapabilities.java
===================================================================
--- /home/ENV/sfarber/dev/geotools/geotools-trunk/module/main/src/org/geotools/filter/FilterCapabilities.java (revision 20947)
+++ /home/ENV/sfarber/dev/geotools/geotools-trunk/module/main/src/org/geotools/filter/FilterCapabilities.java (working copy)
@@ -35,16 +35,6 @@
* Mask for no operation
*/
public static final long NO_OP = 0;
-
- /**
- * Mask for Filter.NONE
- */
- public static final long NONE = 12345;
-
- /**
- * Mask for Filter.ALL
- */
- public static final long ALL = -12345;
// spatial masks
/**
@@ -135,6 +125,16 @@
public static final long LOGIC_NOT = 0x01<<24;
public static final long LOGIC_OR = 0x01<<25;
+
+ /**
+ * Mask for Filter.NONE
+ */
+ public static final long NONE = 0x01<<26;
+
+ /**
+ * Mask for Filter.ALL
+ */
+ public static final long ALL = 0x01<<27;
/**
* Scalar Mask for logical operation
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
