Hi, I agree with contextualizing on Query the various "canXYZ" methods in ContentFeatureSource, and agree on the implementation that deprecates the method without any parameter, having the new one delegate back. It fits just fine with the main branch.
However, I'm worried about the backports. We don't have precedent for deprecating bits of an important API like ContentFeatureSource on stable/maintenance too. What to do? Options: - Don't backport. It's what we normally do, don't think it's what Bjorn needs though. - Backport without deprecation? Would a warning in the javadoc that the method will be deprecated help any? Not sure anyone would read it. - Backport as is. That would be new, don't think it's fair to just deprecate stuff like that in stable (and more importantly, in maintenance) but I'm open to discussion. Cheers Andrea On Fri, Dec 15, 2023 at 1:10 PM Björn Harrtell <bjorn.harrt...@gmail.com> wrote: > Hi, > > TL;DR - I propose to add query as parameter for capability methods like > canOffset in ContentFeatureSource to allow native optimization to be > implemented for specific categories of queries. See JIRA issue at (1). > > Longer story, > > I recently discovered that fetching larger datasets from static files like > FlatGeobuf (and presumably Shapefile?) using paged access (startIndex > offset) is not optimal and will result in "full scans" on each request. > > Currently a datastore must either provide native implementation for all > cases or none based on the boolean answer for a capability. This works fine > for flexible storages like databases and the like which can support these > things generally. However, fx. FlatGeobuf can only support offset in > certain circumstances based on the actual query. For example, it can > support offset on queries for the full dataset without any filtering or > custom ordering but it cannot support offset in combination with an > attribute filter. > > To be able to optimize the queries it can handle it would therefore in > this case be useful to be able implement capabilities so that the answer > can depend on the actual query. > > There has been some informal discussion on the naming sensibility of this > and I suppose there could be an issue that this removes the ability for a > data store to generally advertise that it can do something generally > without supplying an actual query. > > See proposed implementation at (2). > > 1) https://osgeo-org.atlassian.net/browse/GEOT-7509 > 2) https://github.com/geotools/geotools/pull/4593 > > Regards, > Björn Harrtell > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-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
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
