Open jpblair opened 8 years ago
In fact, I was hoping that I would only need to rewrite the process of getting the specific aggregation I need and then it would be the same from there, but the discrepancy appears to apply to all the Aggregation classes.
I agree with @jpblair that it's a painful part of Jest.
I'm currently rewriting an api to use Jest instead of the elasticsearch-client.
For the most part it's pretty easy, mostly changing the RequestBuilders
to SourceBuilders
and a bit of JestResult
validation.
But the Aggregation part is really different from the ES apis and I cannot parse the results the same way I use to do. Because of the work involved I'm currently thinking of rolling back my changes :(
FWIW, if I have to reimplement my aggregation code as a requirement to use Jest, then it's not a total blocker. But if certain parts of the aggregation framework aren't working, then I'm not sure if I'll be able to use Jest. For example, if I read issue #325 correctly, it doesn't look like the Nested aggregation works currently - and the project I'm working on depends on it.
Why does
SearchResult.getAggregations()
return an object of typeio.searchbox.core.search.aggregation.MetricAggregation
instead oforg.elasticsearch.search.aggregations.Aggregations
? Wouldn't it make sense to use the more generic Elasticsearch representation ofAggregations
? I'm currently working on a Jest implementation of a class that uses Spring Data Elasticsearch, and porting would be much easier if I were able to use the same version ofAggregations
that I'm using already.