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
