|
|
Emilio Lahr-Vivaz created an issue |
|
FeatureSizeFeatureCollection causes unoptimized FeatureCollection.size() calls in WFS requests |
|
Issue Type: |
|
|---|---|
|
Affects Versions: |
2.13.0, 2.13.1 |
|
Assignee: |
Unassigned |
|
Components: |
WFS |
|
Created: |
19/Jun/18 7:50 PM |
|
Priority: |
|
|
Reporter: |
|
By default, WFS requests wrap the underlying feature collection with a FeatureSizeFeatureCollection. FeatureSizeFeatureCollection overrides size(), and iterates over all the underlying features if a negative value is returned from the underlying feature collection. I believe that returning -1 is a valid response to size(), and that seemed to be confirmed by Jody in the original PR that added the FeatureSizeFeatureCollection (https://github.com/geoserver/geoserver/pull/1355#issuecomment-263688535). In GeoMesa, by default return we -1, as counts are expensive for us, but we allow overriding that behavior with a system property or a query hint. We have an optimized method to determine counts when needed, which is much faster than iterating over the entire feature collection, but that is being bypassed here. As a proposed solution, I would suggest setting the default value for DEFAULT_CACHE_SIZE to 0 in FeatureSizeFeatureCollection. That way, it would be disabled by default, but could easily be enabled by setting the system property. It seems long-term it would be nice to have a standardized way to request a quick count vs an accurate count. |
|
|
|
Get Jira notifications on your phone! Download the Jira Cloud app for Android or iOS |
|
|
This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087-sha1:a85474e) |
|
|
|