Yes, I remember NativeFilter, there was some discussion about whether to allow that interface to exist at all, the final agreement was that, yes, ok, we can have it, as long as it's a low level programmer oriented tool, which cannot be seen by end users.
And we also have a similar interface for functions called InternalFunction, which has a similar attitude, a function that is not meant to be seen outside of code (cannot be parsed from CQL or Filter XML encoding for example)... although this one has no usage in SQL encoding. Perhaps a NativeFunction base interface could be used, to indicate that the function is not meant to be included in capabilities documents (odd usage, not working cross store), and per store sub-interfaces like PostgisNativeFunction could be used to indicate the function can be written as is in PostGIS for example. I still don't like it much in general, as its usage would be limited to vendor extensions, but I'm not going to cast a -1 either, as I see the convenience of the approach for custom GeoServer extensions. I'll let the other core developers chime in and help with a decision. Cheers Andrea On Tue, Oct 24, 2023 at 6:44 PM Carsten Klein <c.kl...@datagis.com> wrote: > 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 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 > > -- 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
