Use of FilterCapabilities

This page represents the current plan; for discussion please check the tracker link above.

Motivation

Some parts of migrating to opengis Filter are done; this is one aspect of the move that has not yet been addressed.

• opengis FilterCapabilities does not have any knowledge of Filter interfaces; it is slightly higher level in places (reporting back concepts like hasSimpleArithmatic) and slightly lower level in others (reporting back what kind of geometry operands are supported)
• Our SQL generation code uses a deprecated FilterCapabilities data structure built around a mask of deprecated FilterTypes constants.
• We have an FilterCapabilitiesImpl for the opengis FilterCapabilities data structure; but it is not used yet
• There is no sane way to map between the names used by FilterCapabilities Operation entries (like "NullCheck") and GeoAPI Filter interfaces such as PropertyIsNull)
• opengis Function does not report on the number of parameters; that is the responsibility of the filter capabilities data structure FunctionName. Code is currently downcasting to the deprecated FunctionExpression in order to get at this information.
• opengis FilterCapabilities tracks function name and argument count; but gives no indication what the arguments are for.

For reference:

Description

The proposal is to have a Capabilities wrapper / builder around a opengis FilterCapabilities data structure. This proposal only covers creating the utility class; hooking this up to FilterToSQL is another matter.

The idea is to easily switch back and forth between operator names and Filter interface classes (since the mapping is too scary for anyone to remember). As long as we need this class we can make the methods line up with the old FilterCapabilities class (to help people migrate).

OUT OF SCOPE

Above we are defining some methods and classes constants to match the old FilterCapabilities class, we could go even further make everything method and field compatible but that would waste our time:

Status

This proposal has been accepted as the voting period has now ended.

• Andrea Aime +0
• Ian Turton +0
• Justin Deoliveira +0
• Jody Garnett 0 (as a consequence of starting without the voting process)
• Martin Desruisseaux +0
• Simone Giannecchini +0

Tasks

1. Write a Capabilities wrapper around FilterCapabilties data structure to perform tests in a method compatible way with the old FilterCapabilities class
2. Make FilterCapabilitiesImpl data structure mutable so Capabilities wrapper can build it up as needed
3. Add static NAME fields to the GeoAPI interfaces we are trying to map between; even if just to minimize cut and paste mistakes
4. Change FilterCapabilities data structure to use Collection (so we can use a Set behind the scenes)
5. Change Operator interfaces to implement equals and hashCode based on getName()
6. Add FunctionFinder.getFilterCapabilities()
7. Add Function.getArgumentNames() to GeoAPI
8. Migrate FilterToSQLSDE to use new data structure; as an example
9. Create Capabilities and FitlerCapabiities user documentation
10. Suffer a performance review from Andrea - and probably introduce HashMaps rather than HashSets to make lookup faster

API Changes

Create a Capabilities wrapper around FilterCapabilities capturing the mapping from Filter interfaces to Operation.getName().
Where possible make this method comptible with the old FilterCapabilities class.

Add NAME constants to non abstract GeoAPI Filer interfaces

BEFORE:

AFTER:

Adrian Custer asked about the difference here:

• "PropertyIsNull" is from filter.xsd from which we get our Fitler interfaces
• "NullCheck" is from filterCapabilities.xsd from which we get our Operators (describing what filters are allowed).

Ask Operator to be a data object

The interface Operator is part of the filterCapabilities.xsd based data structures.

BEFORE:

AFTER:

Make FilterCapabilitiesImpl mutable

Change the FilterCapabilitiesImpl classes to be mutable, with both a copy constructor and an addAll method for use when combining several FilterCapabilities data structures into one.

BEFORE:

AFTER:

Add Optional getArgumentNames() to FunctionName:

This is an UNRELATED CHANGE THAT WAS FUN (and will let me write a query builder).
BEFORE:

AFTER:

Access Functions data structure from FuntionFinder

The interface Functions is part of the filterCapabilities.xsd based data structures.

BEFORE:

AFTER:

Documentation Changes

• Create a Page for FilterCapabilities
• Create a Page for FilterToSQL