-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Add aggs parsers for high level REST Client #24824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ParsedAggregation is the base Aggregation implementation for the high level client, which parses aggs responses into java objects.
Empty meta gets printed out, which means that if the request contains an empty meta object, that is returned with the response as well. On the other hand null, meaning when the object is not in the request, is not printed out. ParsedAggregation used to not print out empty metadata, and didn't allow the null value. Aligned behaviour to the existing behaviour from InternalAggregation.
Adding parsing of InternalCardinality xContent output. Parsing method will return a new implementation of the Cardinality interface, ParsedCardinality.
…DocValueFormat dep
This commit adds the logic for parsing the percentiles ranks aggregations.
Now the Percentile interface has been merged with the InternalPercentile class in core (#24154) the AbstractParsedPercentiles should use it. This commit also changes InternalPercentilesRanksTestCase so that it now tests the iterator obtained from parsed percentiles ranks aggregations. Adding this new test raised an issue in the iterators where key and value are "swapped" in internal implementations when building the iterators (see InternalTDigestPercentileRanks.Iter constructor that accepts the `keys` as the first parameter named `values`, each key being mapped to the `value` field of Percentile class). This is because percentiles ranks aggs inverts percentiles/values compared to the percentiles aggs. * Add assume in InternalAggregationTestCase * Update after Luca review
…_parsing # Conflicts: # core/src/main/java/org/elasticsearch/search/DocValueFormat.java # core/src/test/java/org/elasticsearch/search/aggregations/InternalAggregationTestCase.java # core/src/test/java/org/elasticsearch/search/aggregations/metrics/InternalMaxTests.java # core/src/test/java/org/elasticsearch/search/aggregations/metrics/avg/InternalAvgTests.java # core/src/test/java/org/elasticsearch/search/aggregations/metrics/min/InternalMinTests.java
#24208) In InternalAggregationTestCase, we can check that the internal aggregation and the parsed aggregation always produce the same XContent even if the original internal aggregation has been shuffled or not.
…_parsing # Conflicts: # core/src/test/java/org/elasticsearch/search/aggregations/metrics/percentiles/InternalPercentilesTestCase.java # core/src/test/java/org/elasticsearch/search/aggregations/metrics/percentiles/hdr/InternalHDRPercentilesTests.java
SearchResponse#fromXContent allows to parse a search response, including search hits, aggregations, suggestions and profile results. Only the aggs that we can parse today are supported (which means all of them but a couple that are left to support). SearchResponseTests reuses the existing test infra to randomize aggregations, suggestions and profile response. Relates to #23331
This method has been removed in core (see #24714)
Now the Java High Level Rest Client has tests to parse all aggregations, this test is not needed anymore. We have better tests like AggregationsTests and sub classes of InternalAggregationTestCase. Related to #23965
…ken (#24794) The method should rather advance one token and only then require a START_OBJECT as the current token. This allows to parse given a parser that's at the beginning of the response, where the initial/current token is null.
Given that both InternalAggregation and ParsedAggregation have this method, it makes sense to move it to the interface they both implement.
Contributor
|
formal LGTM - lets get this in! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the work that has been done on adding parsers for aggregations responses in the feature/client_aggs_parsing branch. All of the aggregations are now supported hence the branch can be merged to master, later on #24796 can be merged to master too so that the high level REST client finally supports _search.
Rather than reusing the classes that already existed for aggregations (which we have done for other apis, or other sections of search), we went for implementing the aggregations interfaces but creating our own classes that we parse responses into. This is because the existing classes are internal classes that hold quite some internal state which would not be available when parsing response back from the REST layer.
The following are all the PRs that were merged to the branch: