Re: [Geotools-devel] (GEOT-895) Unsupported filters should not be sent to Postgis

[Cory H. <ch...@re...>]

Chris Holmes wrote:

> Jesse said the thing that the Filter splitter did better was 
> functions, but looking at the code I'm not sure how that's happening?  
> All I can find is one more FUNCTION capability, that isn't granular at 
> all, and seems to only test the geometryType function.  I would love 
> to see something that properly splits on functions, and indeed encodes 
> functions that it can handle, but this appears not to do it.  Is there 
> a plan to do that?  Or is this really just equivalent?  (I am fine if 
> it's equivalent if you guys prefer to maintain that, since I'm not 
> doing maintenance on SQLUnpacker, though it hasn't needed it for 3 
> years). But yeah, from a geoserver perspective it'd be great if we 
> started to pass functions back to the database to handle where possible.

At the moment PostPreProcessFilterSplittingVisitor only has modest 
improvements over SQLUnpacker, in that it can obtain the delete and 
update filters from the transaction and deal with them appropriately 
(you'll have to ask Jesse how they are used exactly).  You are correct 
in that FunctionExpression handling has not yet been implemented.

On the 2.2.x branch the code did seem to be broken.  The SQLUnpacker was 
being called, but the constructor in JDBC1DataStore.getSqlBuilder was 
not passing the encoder as a parameter; as a result there were no filter 
capabilities and everything got shunted to the post filter.  This 
explains why the getFeatureReader method in JDBC1DataStore had the pre 
filter commented out and was using the post filter, even though this 
doesn't make sense.  This wouldn't be a problem for datastores 
overriding those two methods however, which is likely quite a few.

Anyways, i've just committed some changes (r20584) to 2.2.x i'd like you 
guys to have a look at.  Other modules need to be looked at as well -- 
unfortunately i've left the build in an imperfect state (read: 
incomplete but it compiles).  Some issues still need to be worked out as 
a result, so i've moved /plugin/hsql out of the build for the night.  
I'll have another look in the morning, as wfs and hsql undoubtedly need 
attention.

Can anyone tell me what +/- 12345 (filter type) stands for?

Cheers,
Cory.