Mauro, Those are good points.
I guess my initial instinct is to say that since the three-state implementation of PPPFSV can be 'broken-down' to the two-state PPPFSV (using the method that I pointed out below) then I'd be concerned that we'd be introducing a slightly-too complicated mechanism by implementing a three-state PPPFSV. Besides, even if we implemented a three-state mechanism, the DataStores would still have to declare each of their capabilities in their FilterCaps as 'Fully-supported', 'Partially-supported' or 'Not supported'. By the time that flow (as well as handling the response from the db) was implemented, we could have just as easily modified the DataStore to use the PPPFSV as it currently exists, splitting twice and filtering once on the 'fully-and-partially' supported filters, and once on the 'partially-and-not-at-all' supported filters. All of that said, I think the point about there being some serious optimizations available by 'partially' supporting filters is an extremely important one. Whatever the actual implementation--and I'm not the authority on this one...I'd love to hear what other folks think about this!--this is low-hanging fruit for databases that partially support some spatial operations. We should make sure this information is available to DataStore developers so that they can take advantage of this! thanks much, --saul Mauro Bartolomeoli wrote: > > Looking at the code (gt 2.3.4) I see that the visitor builds 2 stacks > (pre and post). The implemented behavior is this (correct me if I am > wrong): > - if a filter is supported by db it is inserted in the pre stack and > the function returns immediately (so if it is to be preprocessed it > can't be inserted in the postprocessing stack). > - if a filter is not supported by db it is inserted in the post stack. > > My hack consists of not returning from the function when I recognize my > particular filter, so that it can be inserted in both stacks. > > Maybe we should support 3 different states: supported (prestack), not > supported (poststack), partially supported (both pre and post stacks). >> But I'm pretty sure this is a DataStore optimization, and not something >> that >> would need to be changed in PPPFSV. >> > Maybe you're right, the best thing to do is to implement the > optimization in the datastore, I was just wondering if the 3 states > scenario could be useful in other situations. > > Thanks, > Mauro > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > -- View this message in context: http://www.nabble.com/PostPreProcessFilterSplittingVisitor-and-mixed-situations-tf4315906.html#a12296243 Sent from the geotools-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
