IMPLEMENTATION NOTE: This class is implemented as a stack processor. If you're curious how it works, compare it with the old SQLUnpacker class, which did the same thing using recursion in a more straightforward way.
Here's a non-implementors best-guess at the algorithm: Starting at the top of the filter, split each filter into its constituent parts. If the given FilterCapabilities support the given operator, then keep checking downwards.
The key is in knowing whether or not something "down the tree" from you wound up being supported or not. This is where the stacks come in. Right before handing off to accept() the sub- filters, we count how many things are currently on the "can be proccessed by the underlying datastore" stack (the preStack) and we count how many things are currently on the "need to be post- processed" stack.
After the accept() call returns, we look again at the preStack.size() and postStack.size(). If the postStack has grown, that means that there was stuff down in the accept()-ed filter that wasn't supportable. Usually this means that our filter isn't supportable, but not always. In some cases a sub-filter being unsupported isn't necessarily bad, as we can 'unpack' OR statements into AND statements (DeMorgans rule/modus poens) and still see if we can handle the other side of the OR. Same with NOT and certain kinds of AND statements.
In addition this class supports the case where we're doing an split in the middle of a client-side transaction. I.e. imagine doing a
Since GeoTools 8.0, the {@link ClientTransactionAccessor} interface can also be used to instructthe splitter that a filter referencing a given {@link PropertyName} can't be encoded by theback-end, by returning {@link Filter#EXCLUDE} in{@link ClientTransactionAccessor#getUpdateFilter(String) getUpdateFilter(String)}. This is so because there may be the case where some attribute names are encodable to the back-end's query language, while others may not be, or may not be part of the stored data model. In such case, returning {@code Filter.EXCLUDE} makes the filter referencing the property name part of thepost-processing filter instead of the pre-processing filter. @author dzwiers @author commented and ported from gt to ogc filters by saul.farber @author ported to work upon {@code org.geotools.filter.Capabilities} by Gabriel Roldan @source $URL$ @since 2.5.3
|
|
|
|
|
|
|
|