You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#257 addresses the ability to work with additional aggregation types (I think).
I have a case where I am using cardinality aggs to calculate a count in ES, but this kind of aggregation can't be handled at all in the current system.
Even a simple fn raw_aggs(&self) -> Option<&::serde_json::Value> would be acceptable for the time being.
Also, somewhat off-topic, but what is the rationale for flattening typical "bucket" aggs as is done currently? It seems to break with ES conventions without offering any real benefits (in my opinion/as far as I can tell).
The text was updated successfully, but these errors were encountered:
Yes, I've been meaning to generalise our support for aggregations. The original use-case was fairly specific for collecting metrics.
I think an aggs_raw method on SearchResponse that returns a Value is something we'll want to have, even in the future API where we'll keep aggs as Values internally.
#257 addresses the ability to work with additional aggregation types (I think).
I have a case where I am using cardinality aggs to calculate a count in ES, but this kind of aggregation can't be handled at all in the current system.
Even a simple
fn raw_aggs(&self) -> Option<&::serde_json::Value>
would be acceptable for the time being.Also, somewhat off-topic, but what is the rationale for flattening typical "bucket" aggs as is done currently? It seems to break with ES conventions without offering any real benefits (in my opinion/as far as I can tell).
The text was updated successfully, but these errors were encountered: