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

2006-07-17 Thread Cory Horner
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.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel


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

2006-07-17 Thread Chris Holmes



Cory Horner wrote:

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.  
My look at the commit log looks good.  It's going to take a bit of 
testing to make things are right, but the PostGIS classes look nice and 
cleaned up.


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?
I'm pretty sure it's for Filter.ALL and Filter.NONE.  But yeah, they 
could use some better definitions.





Cheers,
Cory.

!DSPAM:1003,44bc3626192171365099012!



--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel