Hi there,
first, many thanks for giving attention to this proposal :-)
Basically, I will be fine with any solution or modification of the
proposal, as long as "SQL Encoding of Vendor Provided Custom Functions"
will be the outcome of the change.
See remarks inline and some summary below:
Discussion:
*
Jody would like to avoid functionality that only works in PostGIS
(for example?) to avoid breaking WFS. *Agree. I guess, this
requires using per-datastore tag interfaces.*
*
Apparently this is already the case with some placeholder
functions (KNN for example)
*
Why? Because then the WFS GetCapabilities advertises functionality
that “does not work” (this is somewhat a limitation of the WFS
standard)
*
Still the approach could be okay for GeoTools Java programmers,
but does it really affect GeoServer?
What to do?
*
SLD already has a mechanism for this? Providing a “fallback value”
if the function is not available in that context … *Havn't looked
into SLD implementation that deep. The Function interface has
support for a fallback value. However, don't know whether SLD
supports specifying a function's fallback value. *
*
We could use the marker interface to avoid listing these functions
in WFS GetCapabilities *We could even invert this and could by
default not list any of these custom functions (the marker
interface could then trigger the function being listed) *
Goal is to make the SQL generation / encoding extensible:
*
seems okay; but is “per datastore” *Yes. That is because GeoTool's
SQL function encoding is already "per datastore" and this proposal
is just a small addition to it. *
*
even that should be fine as long as their is a java fallback so it
can be listed in WFS GetCapabilities
*
If there is no fallback java implementation? Do not list in WFS
GetCapabilities, but could be used in SLD (if there is a fallback
value for safety) *The latter two points are to the vendor's
discretion (using the marker interface) *
The limitations about exact function name match?
*
that is not so good as different databases may have different
function names, or small SQL snippets … *With real project
specific custom functions, one could likely always arrange it so
that the GeoTools function name equals the SQL function's name.
However, this could be done (see below). But, is it really worth it? *
Jody: WIth the changes above I think this could be a good addition…
Action: Wait for Carsten to read the above SQL Function discussion,
and we can discuss further in email
*Fallback Value and WFS GetCapabilities - Summary*
If your biggest concern is, that a function listed in WFS
GetCapabilities will not work with *any* datastore, the simplest
solution could be to generally avoid listing these functions tagged with
the SQLEncodableFunction interface (with no exception using another
marker interface).
Using per-datastore tag interfaces (in contrast to one global tag
interface SQLEncodableFunction) could at least prevent SQL encoding for
those datastores, whose tag interfaces the function's class does not
explicitly implement. Without SQL encoding, the function's Java
implementation is responsible for generating its return value.
However, with SQL encoding of custom functions, there's always the
chance of failure if the SQL function is not available in a certain
database.
*
*
*The limitations about exact function name match*
Simple would be to allow for a different function name in SQL. We could
add a method getSQLFunctionName() to (super) interface
SQLEncodableFunction. Then, in method getFunctionName(Function function)
in class org.geotools.data.jdbc.FilterToSQL (not "per-datastore"!) we
check whether the function is an instance of this interface, get the SQL
function name and return that if it's not null. By using another new
interface for that renaming purpose, this feature would be available for
all functions (independent from this proposal).
More complex would it be to let the function's implementing class
serialize the whole function call on its own (like in e.g.
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-oracle/src/main/java/org/geotools/data/oracle/OracleFilterToSQL.java#L217).
As with the simple SQL name replacement above, a new method
public Object visit(Function function, Object extraData, FilterToSQL
filterToSQL, [DatastoreType datastoreType])
could be declared. Details to be clarified.
This method could even be called datastore independently from
org.geotools.data.jdbc.FilterToSQL.visit(Function function, Object
extraData). However, it would be good to know for what
datastore/database this encoding is for. I've found nothing in
org.geotools.data.jdbc.FilterToSQL that could give us the datastore or
its type. Likely passing the store type as well requires calling this
method from the corresponding visit method in the datastore
implementations using a hard-coded store type ("per-datastore").
Finally, since serializing the function call "manually" should be
optional, the caller of this method must do something like in the
visit(Function, Object) method in the PostGIS datastore when calling the
helper.visitFunction method
(https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/PostgisFilterToSQL.java#L126).
I'm quite unsure whether that complex serialization mechanism is really
needed here.
Carsten
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
