Skip to content
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

Backport aggs parsers for high level REST Client #24844

Merged
merged 67 commits into from
May 24, 2017

Conversation

javanna
Copy link
Member

@javanna javanna commented May 23, 2017

This PR is the backport of #24824 for 5.x. It required a separate PR because in the original feature branch we relied on the aggs test infra that has been recently expanded on master only as part of #22278. Some test classes were missing and are now introduced as part of this PR, yet only the pieces that are needed to test the aggs parsing code rather than all the work done on master. For instance InternalAggregationTestCase is added but it extends ESTestCase rather than AbstractWireSerializingTestCase. The reduce and serialization of aggs is still tested only on master while This PR introduces the testFromXContent test method only, which tests the new parsing code.

The following are all the PRs that were merged to the feature/client_aggs_parsing branch:

In addition to these, the following PRs have been partially backported too:

javanna and others added 30 commits May 22, 2017 13:54
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.
Note that it only extends ESTestCase, it will be used for fromXContent tests only in 5.x

This is a partial backport of elastic#22668
Adding parsing of InternalCardinality xContent output. Parsing method will return a new
implementation of the Cardinality interface, ParsedCardinality.
This commit adds the logic for parsing the percentiles ranks aggregations.
Now the Percentile interface has been merged with the InternalPercentile
class in core (elastic#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
…#24155)

Some aggregations (like Min, Max etc) use a wrong DocValueFormat in
tests (like IP or GeoHash). We should not test aggregations that expect
a numeric value with a DocValueFormat like IP. Such wrong DocValueFormat
can also prevent the aggregation to be rendered as ToXContent, and this
will be an issue for the High Level Rest Client tests which expect to be
able to parse back aggregations.
elastic#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.
…stic#24291)

The `count` value in the stats aggregation represents a simple doc count
that doesn't require a formatted version. We didn't render an "as_string"
version for count in the rest response, so the method should also be
removed in favour of just using String.valueOf(getCount()) if a string
version of the count is needed.

Closes elastic#24287
cbuescher and others added 22 commits May 23, 2017 11:58
This adds parsing to all implementations of SingleBucketAggregations. They are mostly similar, so they share the common
base class `ParsedSingleBucketAggregation` and the shared base test `InternalSingleBucketAggregationTestCase`.
… make use of it from other modules.

This is a partial backport of elastic#24559
This adds parsing to the InternalFilters aggregation.
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 elastic#23331
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 elastic#23965
…ken (elastic#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.
Copy link
Member

@cbuescher cbuescher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM allthough due to the size I just glanced over the ParsedAggregation implementations. I left two really small nits on a method in InternalStats that was deprecated in 5.x, so it would be nice to keep it in 5 and let it be removed only in 6.

@@ -112,11 +112,6 @@ public double getSum() {
}

@Override
public String getCountAsString() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: This was only deprecated in 5, so maybe we can leave this in.

* @deprecated use String.valueOf(getCount()) instead if the count is needed as a string
*/
@Deprecated
String getCountAsString();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: This was only deprecated in 5, so maybe we can leave this in.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would need to add this deprecated method to ParsedStats too, and I am not sure what it would return. I don't think it is worth the trouble. That is why I removed it, it was not necessary to deprecate it in the first place.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I just wanted to ask if it was a concious decision or not.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++ good call

Copy link
Member

@tlrx tlrx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@javanna javanna merged commit 59179ce into elastic:5.x May 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants