Chris Holmes wrote: > Huh? What is going on? JDBC, which PostGIS inherits from, already > does pre and post filter processing based on capabilities, by way of > SQLUnpacker (yes somewhat poorly named). That was the whole reason > filter capabilities were invented, to do pre and post filter splitting > with SQLUnpacker. > > I wrote the original code, and though I'm not really that attached to > it, it should at least be fully replaced in the right manner, not in a > half assed way in one of the jdbc sub-classes. SQLUnpacker (in main, > org.geotools.filter) is used in DefaultSQLBuilder (in main, > org.geotools.data.jdbc), so if you really want to use the > PostPreProcessFilterSplittingVisitor (ok, my name sucks, but that's > not much better), replace it there. And don't add nasty static > capability additions. The capabilities are already added in the > PostGIS Filter classes in org.geotools.filter in the postGIS package. > Also your implementation doesn't seem to take GEOS presence in to > account at all? The spatial filter capabilities should only be added > if GEOS is present. > > And I sorta would like to hear the justification as to why the new > filter splitter is better than the old? I'm totally willing to > concede that it is, but if it's better, it should really replace it > all, instead of breaking the decomposition we did before. Are the > masks really that much faster? Is this operation performed many times > so that the difference matters? If not then I find the masks less > readable - it feels more like programmer wanking. But I do agree that > dueling FilterCapabilities should be combined so nice work on that, > David and I talked about doing it. But if you're moving the new > processing in to PostGIS, put it in the right place in the SQLBuilder > and don't litter it with a bunch of new methods and static adding of > filter capabilities. > > But yeah, your new patch is _more_ likely to send unsupported filters > to PostGIS, since it will do so when there's no GEOS present, in > addition to adding unnecessary cruft to the already crowded > PostGISDataStore when we've already decomposed it nicely to different > classes, including ones in the parent class so others can use it.
I wasn't aware that a functioning pre and post filter processing method was in existence. In PostGIS and WFS such code was certainly broken or incomplete. We will take a closer look, and rewrite as necessary. Cory. ------------------------------------------------------------------------- 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
