I was not considering back porting as this is an API change? Admittedly only a protected API between superclass and implementation.
If we really need to backport then option 2 is the only one. -- Jody Garnett On Mon, Dec 18, 2023 at 6:04 AM Andrea Aime < andrea.a...@geosolutionsgroup.com> wrote: > 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 >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
