Sort of on track. First class functions have both a java implementation and a way to be delegated to the database.
There are however a few functions that have no equivalent and can be run only against a particular database, like pgNearest: https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/filter/FilterFunction_pgNearest.java These functions still have to be recognized as part of the filter capabilities and have custom encoding code: https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L196 The downside of these is that they make for a broken system, the moment there is more than one backend data source, or just by the fact of being there. E.g., pgNearest is always there as postgresql store is always included, but installations might be using Oracle, sql server, shapefiles, all sources where attempting usage of such function will fail. So it's not clean, but also normally not a big deal because the description of functions in WFS capabilities is so poor that clients cannot automatically use them anyways, clients using functions are usually written by hand anyways. Cheers Andrea On Tue, Sep 26, 2023 at 9:01 AM Carsten Klein <c.kl...@datagis.com> wrote: > Hi Jody, > > thanks for your response :) > > Since I will likely not be able to modify/extend FilterToSqlHelper from a > GeoTools Filter Function Plugin, it will be best to focus on PostgreSQL > functions that can be encoded as > > functionName(p1, p2, ... pN) > > In that case, PostgisFilterToSQL will translate my Java implemented custom > functions to SQL without any further action required? (Given that "encode > functions" is enabled.) > > I guess, the actual Java implementation is not required to return/evaluate > any meaningful results based on the arguments, right? (I won't be able to > re-implement e.g. Full Text Search in Java, of course) > > Still on track? > > Regards, > Carsten > > > Am 26.09.2023 um 08:31 schrieb Jody Garnett: > > You are running alongside the right track :) > > To work you implement in java (for any non PostGIS data) and then adjust > the PostGIS DataStore code to map those functions to SQL. > > - PostGISDialect > - PostgisFIlterToSQL > - FilterToSqlHelper > - FilterToSqlHelper.visitFunction(function,extraData) > > <https://github.com/geotools/geotools/blob/main/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/FilterToSqlHelper.java#L522> > > > You can see the mapping being done from the GeoTools function data > structure (which is why you need a java implementation) to the SQL. > > > -- > Jody Garnett > > > On Sep 25, 2023 at 11:23:00 PM, Carsten Klein <c.kl...@datagis.com> wrote: > >> Hi there, >> >> I'd like to use some custom PostgreSQL functions as filters in standard >> WFS 2.0.0 requests. The goal is to request features filtered by e.g. >> Full Text Search or the word_similarity function provided by the pg_trgm >> extension (Trigram/Trigraph support). >> >> Since WFS only provides a quite limited set of operators >> (PropertyIs[Not]EqualTo, PropertyIsLessThan, PropertyIsLike, etc.), my >> idea is to use my own filter functions in order to access those custom >> database functions. >> >> In GeoTools, there is a Function tutorial explaining how to create my >> own Function Factory and function implementations. However, all samples >> and functions I've seen so far are implemented in Java. Is it possible >> for these Filter Functions to contribute to the WHERE clause of the >> actual SQL statement executed in the database? >> >> For a GeoServer (Data)Store, there is an option "encode functions", >> causing all/most filters to be implemented in SQL for performance >> reasons. Does this affect Filter Functions from those Filter Factories >> as well? >> >> Looking at the Function's interfaces (Expression, ExpressionVisitor, >> Function), I don't see any point at which SQL could come into play. Am I >> on the right track? >> >> Any advice is appreciated :) >> >> Carsten >> >> >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://www.geosolutionsgroup.com/ 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
