Hi Jody,
coming back to this quite late. Sorry for that. The project that
requires these custom filter functions has already started and must be
finished on July 1, 2024... It's a lot of work and I and my team are
really busy now. Also, the SQL encodable custom filter functions is only
a very small part of the project.
Let me just focus on some of your questions:
* The proposal is not complete
o Tasks are not filled in; so I am not what is required, and if
you need help or collaborators to be successful
o API Change is not filled in so I do not know exactly what you
are proposing
As a response to my proposal I was expecting a discussion about how and
where to implement the new interface(s). I thought, that API changes
could be defined only afterwards.
* Have to be careful not get get dependencies from the function to
the datastore
o We cannot have a dependency from the function implementation,
to an interface in a specific datastore
o We should not assume the datastore is available on the
classpath , the function may be used on its own
o The FilterCapabilities are processed by GeoServer to come up
with a function list; need to ensure we do not mess that API
contract up. A lot of that contract will be in javadocs;
perhaps not expressed clearly (as they often assume
familiarity with the WFS specification
My first and simplest idea was to add a single GeoTools Core interface,
which does not introduce a dependency from functions to datastores.
AFAIK, Andrea came up with the idea to have several datastore specific
tag interfaces (in order to address the problem that such functions only
work with certain datastores).
Andrea pointed out a few places where we already know there is a
problem (some PostGIS specific functions) <-- this is a good test of
your proposed change? Can it handle these two functions and fix some
technical debt that occurred when we were not being careful about
function boundaries...
No, that's likely not a good test of my proposed change, since I never
intended to solve any existing problems in GeoTools. I just asked to add
a new single interface in GT core and add this to the list of SQL
encodable functions (like you already did with the NativeFilter class).
Didn't think that there is much need for a BEFORE/AFTER API change
discussion in advance.
My proposal was about project specific externally implemented custom
filter functions. These typically are only present in one single
installation. So, why bothering about the fact, that these functions
will only work in PostGIS and not in Oracle, when PostgreSQL is the
project's only database?
Of course I understand that you must account for the wider systems. And
yes, often things thought simple are no longer that simple in a larger
project. That may be true even for adding a new interface. I just have
far too less knowledge about GeoTools internals.
However, I guess that I do not have the time for attending this proposal
any further (remind July 1, 2024 ... ).
Instead, last night, I've found a surprisingly simple solution for my
problem: I'm using a filter function that gets SQL encoded with PostGIS
as the base class of my new custom filter functions. Since that must be
a filter function with no custom visits (aka SQL encoding, see
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L522),
I decided to derive my filter function classes from FilterFunction_ceil:
public abstract class MyCustomFilterFunction extends FilterFunction_ceil {
public MyCustomFilterFunction (
FunctionNameImpl name, List<Expression> parameters, Literal
fallback) {
this.functionName = name;
this.name = name.getName();
this.setParameters(parameters);
this.setFallbackValue(fallback);
}
[...]
}
Since my filter function now is also an instance of FilterFunction_ceil,
it gets encoded into SQL when the "encode function" option is set to
true. In other words, I'm abusing class FilterFunction_ceil as the new
tag interface I was asking for... Actually, this works great (and should
not stop working until someone either removes FilterFunction_ceil or
removes it from the list of SQL encodable functions for the PostGIS store).
Nonetheless many thanks for your support. Maybe we could get back to
this in the near future.
Cheers
Carsten
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
