sfarber wrote: > Mauro, > > That's actually a very interesting use-case, and not one that I'd though of > before (although it makes a lot of sense!) > > I'm not sure that PPPFSV prevents what you're describing from happening, > however. I think it's more about how the DataStore handles what the PPPFSV > returns. > 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
