Another idea:
Couldn't there be a more extensible way to declare a SPI provided
function "SQL encodable" for a certain Store (e.g. PostGIS)? Maybe
a tag interface "SqlEncodable" could do that job?
No, it does not make sense... a filter may be sql encodable in one
database, but not in another, and a function is available
for the whole system. I doubt there are many functions that are sql
encodable in all databases we support.
Why not using N tag interfaces, one per DataStore?
You could define tag interface
org.geotools.data.postgis.PostgisSQLEncodable in plugin jdbc-postgres.
This type could unconditionally be added to FilterCapabilities in
createFilterCapabilities in class FilterToSqlHelper:
caps.addType(PostgisSQLEncodable.class);
Implementors of plugin-defined filter functions could then implement the
tag interface(s) that corresponds to the desired DataStore(s) (if
available). Of course, that mechanism is not ideal for built-in
functions, which aim to be generally available (aka work with
DataStores). But, this is likely much simpler than implementing another
SPI...
You can repeat the above steps e. g. for jdbc-oracle, jdbc-mysql, etc.
But that's not a MUST - such a tag interface is not required to be
available for all DataStore implementations (for me, supporting PostGIS
will be sufficient *g*). But for the sake of completeness, most (major)
DataSores should get their tag interface, of course.
Cheers
Carsten
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
