I think I can live with targeting GeoServer 2.25.0, i.e option 1 is fine for me.
Den mån 18 dec. 2023 kl 16:21 skrev Jody Garnett <jody.garn...@gmail.com>: > 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
