Made all multi-bucket aggs return consistent response format
Closes #4926
This commit is contained in:
parent
f9d1552282
commit
dd389d1cc5
|
@ -111,7 +111,8 @@ Response:
|
|||
--------------------------------------------------
|
||||
{
|
||||
"aggregations": {
|
||||
"articles_over_time": [
|
||||
"articles_over_time": {
|
||||
"buckets": [
|
||||
{
|
||||
"key_as_string": "2013-02-02",
|
||||
"key": 1328140800000,
|
||||
|
@ -126,6 +127,7 @@ Response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
Like with the normal <<search-aggregations-bucket-histogram-aggregation,histogram>>, both document level scripts and
|
||||
|
|
|
@ -34,7 +34,8 @@ Response:
|
|||
...
|
||||
|
||||
"aggregations": {
|
||||
"range": [
|
||||
"range": {
|
||||
"buckets": [
|
||||
{
|
||||
"to": 1.3437792E+12,
|
||||
"to_as_string": "08-2012",
|
||||
|
@ -48,6 +49,7 @@ Response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
[[date-format-pattern]]
|
||||
|
|
|
@ -28,7 +28,8 @@ Response:
|
|||
--------------------------------------------------
|
||||
{
|
||||
"aggregations": {
|
||||
"rings": [
|
||||
"rings" : {
|
||||
"buckets": [
|
||||
{
|
||||
"unit": "km",
|
||||
"to": 100.0,
|
||||
|
@ -48,6 +49,7 @@ Response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
The specified field must be of type `geo_point` (which can only be set explicitly in the mappings). And it can also hold an array of `geo_point` fields, in which case all will be taken into account during aggregation. The origin point can accept all formats supported by the `geo_point` <<mapping-geo-point-type,type>>:
|
||||
|
|
|
@ -34,7 +34,8 @@ And the following may be the response:
|
|||
--------------------------------------------------
|
||||
{
|
||||
"aggregations": {
|
||||
"prices": [
|
||||
"prices" : {
|
||||
"buckets": [
|
||||
{
|
||||
"key": 0,
|
||||
"doc_count": 2
|
||||
|
@ -50,6 +51,7 @@ And the following may be the response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
The response above shows that none of the aggregated products has a price that falls within the range of `[100 - 150)`. By default, the response will only contain the non-empty buckets, though it is possible to also return those, by setting the `empty_buckets` flag to `true`:
|
||||
|
@ -75,7 +77,8 @@ Response:
|
|||
--------------------------------------------------
|
||||
{
|
||||
"aggregations": {
|
||||
"prices": [
|
||||
"prices" : {
|
||||
"buckets": [
|
||||
{
|
||||
"key": 0,
|
||||
"doc_count": 2
|
||||
|
@ -95,6 +98,7 @@ Response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
==== Order
|
||||
|
@ -187,6 +191,7 @@ NOTE: The special value `0` can be used to add empty buckets to the response b
|
|||
{
|
||||
"aggregations": {
|
||||
"prices": {
|
||||
"buckets": {
|
||||
"0": {
|
||||
"key": 0,
|
||||
"doc_count": 2
|
||||
|
@ -214,6 +219,7 @@ NOTE: The special value `0` can be used to add empty buckets to the response b
|
|||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
==== Response Format
|
||||
|
@ -242,6 +248,7 @@ Response:
|
|||
{
|
||||
"aggregations": {
|
||||
"prices": {
|
||||
"buckets": {
|
||||
"0": {
|
||||
"key": 0,
|
||||
"doc_count": 2
|
||||
|
@ -257,4 +264,5 @@ Response:
|
|||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -30,7 +30,8 @@ Response:
|
|||
...
|
||||
|
||||
"aggregations": {
|
||||
"ip_ranges": [
|
||||
"ip_ranges":
|
||||
"buckets" : [
|
||||
{
|
||||
"to": 167772165,
|
||||
"to_as_string": "10.0.0.5",
|
||||
|
@ -44,6 +45,7 @@ Response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
IP ranges can also be defined as CIDR masks:
|
||||
|
@ -71,7 +73,8 @@ Response:
|
|||
--------------------------------------------------
|
||||
{
|
||||
"aggregations": {
|
||||
"ip_ranges": [
|
||||
"ip_ranges": {
|
||||
"buckets": [
|
||||
{
|
||||
"key": "10.0.0.0/25",
|
||||
"from": 1.6777216E+8,
|
||||
|
@ -91,4 +94,5 @@ Response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
|
@ -31,7 +31,8 @@ Response:
|
|||
...
|
||||
|
||||
"aggregations": {
|
||||
"price_ranges": [
|
||||
"price_ranges" : {
|
||||
"buckets": [
|
||||
{
|
||||
"to": 50,
|
||||
"doc_count": 2
|
||||
|
@ -48,6 +49,7 @@ Response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
==== Keyed Response
|
||||
|
@ -82,6 +84,7 @@ Response:
|
|||
|
||||
"aggregations": {
|
||||
"price_ranges" : {
|
||||
"buckets": {
|
||||
"*-50.0": {
|
||||
"to": 50,
|
||||
"doc_count": 2
|
||||
|
@ -98,6 +101,7 @@ Response:
|
|||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
It is also possible to customize the key for each range:
|
||||
|
@ -200,7 +204,8 @@ Response:
|
|||
--------------------------------------------------
|
||||
{
|
||||
"aggregations": {
|
||||
"price_ranges": [
|
||||
"price_ranges" : {
|
||||
"buckets": [
|
||||
{
|
||||
"to": 50,
|
||||
"doc_count": 2,
|
||||
|
@ -238,6 +243,7 @@ Response:
|
|||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
If a sub aggregation is also based on the same value source as the range aggregation (like the `stats` aggregation in the example above) it is possible to leave out the value source definition for it. The following will return the same response as above:
|
||||
|
|
|
@ -274,8 +274,8 @@ There are two mechanisms by which terms aggregations can be executed: either by
|
|||
data per-bucket (`map`), or by using ordinals of the field values instead of the values themselves (`ordinals`). Although the
|
||||
latter execution mode can be expected to be slightly faster, it is only available for use when the underlying data source exposes
|
||||
those terms ordinals. Moreover, it may actually be slower if most field values are unique. Elasticsearch tries to have sensible
|
||||
defaults when it comes to the execution mode that should be used, but in case you know that an execution mode may perform better
|
||||
than the other one, you have the ability to provide Elasticsearch with a hint:
|
||||
defaults when it comes to the execution mode that should be used, but in case you know that one execution mode may perform better
|
||||
than the other one, you have the ability to "hint" it to Elasticsearch:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -363,10 +363,11 @@ public class InternalHistogram<B extends InternalHistogram.Bucket> extends Inter
|
|||
|
||||
@Override
|
||||
public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException {
|
||||
if (keyed) {
|
||||
builder.startObject(name);
|
||||
if (keyed) {
|
||||
builder.startObject(CommonFields.BUCKETS);
|
||||
} else {
|
||||
builder.startArray(name);
|
||||
builder.startArray(CommonFields.BUCKETS);
|
||||
}
|
||||
|
||||
for (B bucket : buckets) {
|
||||
|
@ -396,7 +397,7 @@ public class InternalHistogram<B extends InternalHistogram.Bucket> extends Inter
|
|||
} else {
|
||||
builder.endArray();
|
||||
}
|
||||
return builder;
|
||||
return builder.endObject();
|
||||
}
|
||||
|
||||
}
|
||||
|
|
|
@ -294,26 +294,27 @@ public class InternalRange<B extends InternalRange.Bucket> extends InternalAggre
|
|||
out.writeDouble(((Bucket) bucket).from);
|
||||
out.writeDouble(((Bucket) bucket).to);
|
||||
out.writeVLong(((Bucket) bucket).docCount);
|
||||
((Bucket) bucket).aggregations.writeTo(out);
|
||||
bucket.aggregations.writeTo(out);
|
||||
}
|
||||
}
|
||||
|
||||
@Override
|
||||
public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException {
|
||||
if (keyed) {
|
||||
builder.startObject(name);
|
||||
if (keyed) {
|
||||
builder.startObject(CommonFields.BUCKETS);
|
||||
} else {
|
||||
builder.startArray(name);
|
||||
builder.startArray(CommonFields.BUCKETS);
|
||||
}
|
||||
for (B range : ranges) {
|
||||
((Bucket) range).toXContent(builder, params, formatter, keyed);
|
||||
range.toXContent(builder, params, formatter, keyed);
|
||||
}
|
||||
if (keyed) {
|
||||
builder.endObject();
|
||||
} else {
|
||||
builder.endArray();
|
||||
}
|
||||
return builder;
|
||||
return builder.endObject();
|
||||
}
|
||||
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue