Summary of request
The current network search functionality supports only keyword aggregations. To bring it to parity with Arranger's local search, the numeric aggregation fields need to be supported in network search.
Currently, numeric fields are being filtered out of the network schema and search resolution.
This work should make all numeric fields available for network search.
Details
The specific limitation that caused this aggregation type to be disabled in the initial network search implementation is that numeric search groups the data into ranges, and those ranges won't be consistent across the network. This means that the default implementation is not able to provide aggregated data across all nodes, but will instead provide per-node bucketing of the data. A strategy needs to be chosen and implemented to pre-define these buckets on the local search node so that the same buckets are fetched from each remote node. Once all network queries define the numeric range buckets and use them consistently across all remote node queries then the numeric aggregations will be usable.
There are two cases to consider: when the network query includes the numeric range (and number of divisions) to query, and then the default case where the query does not include this value.
When the query includes the ranges to query, this removes the issue since those ranges can be applied to the query sent to all remote nodes.
When the query DOES NOT include ranges, the behaviour is undefined and by default the buckets returned by each node are defined by the available data - the resulting responses from remote nodes cannot be aggregated.
Desired solution
The simplest solution is to always require user defined data ranges. This pushes the solution to the UI or other client, but means that all queries will be aggregated in a consistent way that satisfies the user.
The ideal solution would be able to smartly determine the total range of data across all nodes and generate buckets that cover that full range.
The specific solution is not defined here, but is required before implementation.
Summary of request
The current network search functionality supports only keyword aggregations. To bring it to parity with Arranger's local search, the numeric aggregation fields need to be supported in network search.
Currently, numeric fields are being filtered out of the network schema and search resolution.
This work should make all numeric fields available for network search.
Details
The specific limitation that caused this aggregation type to be disabled in the initial network search implementation is that numeric search groups the data into ranges, and those ranges won't be consistent across the network. This means that the default implementation is not able to provide aggregated data across all nodes, but will instead provide per-node bucketing of the data. A strategy needs to be chosen and implemented to pre-define these buckets on the local search node so that the same buckets are fetched from each remote node. Once all network queries define the numeric range buckets and use them consistently across all remote node queries then the numeric aggregations will be usable.
There are two cases to consider: when the network query includes the numeric range (and number of divisions) to query, and then the default case where the query does not include this value.
When the query includes the ranges to query, this removes the issue since those ranges can be applied to the query sent to all remote nodes.
When the query DOES NOT include ranges, the behaviour is undefined and by default the buckets returned by each node are defined by the available data - the resulting responses from remote nodes cannot be aggregated.
Desired solution
The simplest solution is to always require user defined data ranges. This pushes the solution to the UI or other client, but means that all queries will be aggregated in a consistent way that satisfies the user.
The ideal solution would be able to smartly determine the total range of data across all nodes and generate buckets that cover that full range.
The specific solution is not defined here, but is required before implementation.