Hi Andrea,
see my comments inline:
Cheers
Carsten
Am 24.10.2023 um 15:30 schrieb Andrea Aime:
Hi Carsten,
I'm skeptical, the idea would not be applicable to existing GeoTools
functions as
it would end up introducing circularities in the maven module
dependencies.
The PostGIS interface would be found in gt-jdbc-postigs, but most
existing functions
are found in gt-main. And if we wanted to have a function translatable
in multiple
databases, the code would have to depend on all the associated
gt-jdbc-<dbhere> modules.
A mechanism that can only be used only downstreams, but not by the
library itself,
does not seem very interesting to me.
That was meant as an extension point for user-provided filter functions.
Not as a replacement
mechanism to make existing filter functions SQL-encodable. Such custom
filter functions typically
are implemented only on one certain database (e.g. PostGIS or Oracle,
but not both) so, a provider
of such a function only has to reference gt-main and e. g.
gt-jdbc-postgis OR gt-jdbc-oracle (but not
all of them).
However, a common solution for both internal existing and user-provided
filter functions is actually
charming... Maybe the annotation approach is the best idea for that. On
the other side, that is a lot
of work to be done.
Also, I'm not sure there is a simple way to check if a function
implements a given interface,
what we can get from FunctionFinder is a list of FunctionName, and in
order to instantiate
a particular function, one has to pass an actual list of arguments.
Did you think about how you'd
like to actually implement the lookup?
Actually, that's quite simple and works with the
org.geotools.filter.FilterCapabilities (which already
does an isAssignableFrom in its supports method). As you can see in class
https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L134
for PostGIS, each SQL-encodable function's class is added to the created
FilterCapabilities 'caps'
through the addType method. In lines 207 and 208 you can see, that the
NativeFilter interface is
also added. If the newly (maybe dbytpe-specific) interface is added here
as well, everything
should work just out of the box.
Putting all together: yes, this is just for downstreams and it's not the
answer to everything. But, besides
the new interfaces (one per dbtype) it requires only one line of code
(plus a comment line, if you like) per
dbtype. For me, this seems quite cheap, even if it's a feature for
externally defined filter functions only.
I can see it working with CommonFactoryFinder.getFunctions, which
would limit the mechanism
to the single function SPI, rather than being more comprehensive and
cover the FunctionFactory
mechanism (which is the original one, the single Function one has been
added afterward as a
convenience).
Gut feeling, maybe it would be better to use a common annotation
instead, receiving multiple
strings, which would be the "dbtype" of the database where it can be
encoded without any
translation. This would avoid the circularities. It would still be
limited to standalone functions API,
but I don't see much of a way around that, without somehow extending
FunctionName to support
JDBC encoding (which sounds like it would be another bad idea).
Jody, any other suggestion?
Cheers
Andrea
On Tue, Oct 24, 2023 at 8:10 AM Carsten Klein <c.kl...@datagis.com> wrote:
Hi Andrea,
hi Jody,
any progress here? For me, the interface-based approach seems
quite simple and is likely easy to implement. What do you think
about it? Would be great if we could get things moving...
Cheers
Carsten
--
Regards,
Andrea Aime
==GeoServer Professional Services from the experts!
Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for
more information.==Ing. Andrea Aime @geowolfTechnical Lead
GeoSolutions Groupphone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/>
http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it>
-------------------------------------------------------
Con riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati
“GDPR”), si precisa che ogni circostanza inerente alla presente email
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui
conoscenza è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato
se potesse darmene notizia.This email is intended only for the person
or entity to which it is addressed and may contain information that is
privileged, confidential or otherwise protected from disclosure. We
remind that - as provided by European Regulation 2016/679 “GDPR” -
copying, dissemination or use of this e-mail or the information herein
by anyone other than the intended recipient is prohibited. If you have
received this email by mistake, please notify us immediately by
telephone or e-mail
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
