Return the aggregation type in the response

[Mpdreamz]

Right now aggregations responses are hard to differentiate if you do not know how they were originally constructed.

In the .NET client I manage just about to peace back together the type of the aggregations by doing some simple property inspection.

For now this works even with the newly added 1.1 aggregations but I fear this approach won't scale in the long run.

If I could specify a agg_type_hint flag on the search requests so aggregations are returned like this:

"aggregations": {
  "myagg": {
     "_type": "nested",
     "doc_count": 2
  }
}

I could parse the aggregations to a typed response a lot easier without having the hold a ref to original search request object.

Note: I'm working on a PR for this

[uboness]

not sure about this... first I'm not sure it's really needed... second, if it is something ppl would really like to have, this feels like a partial feature, if we go down this route, I'd rather return the full agg configuration, not just the type (for example, I believe ppl asked in the past to get back the interval of the histos along with the response).

@clintongormley @jpountz what do you think?

[clintongormley]

Hmm, it makes more sense to me to just hang on to the original request, rather than to pass the config back over the wire again, same as we do bulk and mget. But maybe this is easier to do in a scripting language than in .net

[uboness]

yeah... I'd prefer to hang on original request as well... it feels wrong from many perspectives and inconsistent with other apis (as @clintongormley mentioned, bulk and mget, but one could also ask why we don't return the query back together with the search response).

[Mpdreamz]

I have to respectfully disagree with both of you here :)

This is how a facet response looks like:

"facets": {
      "myfacet": {
         "_type": "terms",
         "missing": 0,
         "total": 2,
         "other": 0,
         "terms": []
      }
   },

So spitting out _type for aggregations makes it actually all the more consistent.

Having deserialization state is a real pain in .NET since the whole deserialization is a single pass and most serializers can not hold state while creating custom converters. I had to piggy back in a very hackish manner in JSON.NET to support multi_search mget bulk responses and the fact that I had to do so made injecting other serializers in NEST (not Elasticsearch.Net btw) impossible..

[jpountz]

I'm afraid giving the whole configuration back would make the response bloated. But on the other hand if we start giving options in order to only render the type or the interval, it would be a pain to test.

Maybe something that would be flexible and reasonably easy to do/test/maintain would be to let users add arbitrary metadata to aggregations at query time that we would render back in the aggregations response. This way, if a client needs the aggregation type to make deserialization easier, it could just add it to this metadata (same for histogram interval)?

[Mpdreamz]

This isn't about configuration or request state though is about giving enough information back to be able to deserialize/know what we the thing that is being returned actually is.

To me returning _type here is not analogous to returning the original query on search results or passed options to the aggregations itself.

[Mpdreamz]

@jpountz I implemented the ability to attach arbitrary metadata to aggregations here #6465 would love a review whenever is convenient for you :)

[clintongormley]

Closed by #8279