Make Terms.Bucket an interface rather than an abstract class #24492
Conversation
This file contains 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
This commit changes the Terms.Bucket abstract class to an interface, so that it's easier for the Java High Level Rest Client to provide its own implementation. In its current state, the Terms.Bucket abstract class inherits from InternalMultiBucketAggregation.InternalBucket which forces subclasses to implement Writeable and exposes a public getProperty() method that relies on InternalAggregation. This two points make it difficult for the Java High Level Rest Client to implement the Terms and Terms.Bucket correctly. This is also different from other MultiBucketsAggregation like Range which are pure interfaces. Changing Terms.Bucket to an interface causes a method clashes for the `getBuckets()` method in InternalTerms. This is because: - InternalTerms implements Terms which declared a `List<Terms.Bucket> getBuckets()` method - InternalTerms extends InternalMultiBucketAggregation which declares a `List<? extends InternalBucket> getBuckets()` method - both overrides the MultiBucketsAggregation `List<? extends Bucket> getBuckets()` method There was no clashes before this change because Terms.Bucket extends InternalBucket and conformed to both declaration. With Terms.Bucket now an interface, the getBuckets() method in the Terms interface is changed to avoid method clash. This is a breaking change in the Java API but it's a straightforward change and the Terms multi bucket aggregation interface is also more coherent with the other Range, Histogram, Filters, AdjacencyMatrix etc that all return a `List<? extends Bucket>`.
javanna
changed the title
|
Thanks @javanna ! |
tlrx
added a commit
that referenced
this pull request
May 5, 2017
This commit changes the Terms.Bucket abstract class to an interface, so that it's easier for the Java High Level Rest Client to provide its own implementation. In its current state, the Terms.Bucket abstract class inherits from InternalMultiBucketAggregation.InternalBucket which forces subclasses to implement Writeable and exposes a public getProperty() method that relies on InternalAggregation. This two points make it difficult for the Java High Level Rest Client to implement the Terms and Terms.Bucket correctly. This is also different from other MultiBucketsAggregation like Range which are pure interfaces. Changing Terms.Bucket to an interface causes a method clashes for the `getBuckets()` method in InternalTerms. This is because: - InternalTerms implements Terms which declared a `List<Terms.Bucket> getBuckets()` method - InternalTerms extends InternalMultiBucketAggregation which declares a `List<? extends InternalBucket> getBuckets()` method - both overrides the MultiBucketsAggregation `List<? extends Bucket> getBuckets()` method There was no clashes before this change because Terms.Bucket extends InternalBucket and conformed to both declaration. With Terms.Bucket now an interface, the getBuckets() method in the Terms interface is changed to avoid method clash. This is a breaking change in the Java API but it's a straightforward change and the Terms multi bucket aggregation interface is also more coherent with the other Range, Histogram, Filters, AdjacencyMatrix etc that all return a `List<? extends Bucket>`. (cherry picked from commit 7bd2abe)
jasontedor
added a commit
to jasontedor/elasticsearch
that referenced
this pull request
May 6, 2017
* master: Fix plugin installation permissions Remove unneeded empty string concatentation TimeValue#parseTimeValue author is bad, feels bad Add workaround so path.data can be set in run task Change Terms.Bucket to an interface (elastic#24492) Update completion-suggest.asciidoc (elastic#24506) Add new ip_range field type Expand cross cluster search indices for search requests to the concrete index or to it's aliases (elastic#24502) Fixed docs syntax for for-in loop in painless [TEST] Reenable disabled tests for _field_caps and _search_shards (elastic#24505)
SGM3
added a commit
to SGM3/liferay-portal
that referenced
this pull request
Jul 6, 2017
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 commit changes the
Terms.Bucketabstract class to an interface, so that it's easier for the Java High Level Rest Client to provide its own implementation.In its current state, the Terms.Bucket abstract class inherits from InternalMultiBucketAggregation.InternalBucket which forces subclasses to implement
Writeableand to expose a publicgetProperty()method that relies on InternalAggregation. This two points make it difficult for the Java High Level Rest Client to implement the Terms and Terms.Bucket correctly. This is also different from other MultiBucketsAggregation like Range which are pure interfaces.Sadly, changing Terms.Bucket to an interface caused a method clash for the
getBuckets()method in InternalTerms because:List<Terms.Bucket> getBuckets()methodList<? extends InternalBucket> getBuckets()methodand both overrides the MultiBucketsAggregation
List<? extends Bucket> getBuckets()method.There was no clashes before this change because Terms.Bucket extends InternalBucket and conformed to both declarations. With Terms.Bucket now an interface, this commit changes the getBuckets() method in the Terms interface so that it now returns
List<? extends Bucket>instead ofList<Terms.Bucket>. I didn't see a better way to do this.This is a breaking change in the Java API but it's a straightforward change and the Terms multi bucket aggregation interface is also more coherent with the other Range, Histogram, Filters, AdjacencyMatrix etc that all return a
List<? extends Bucket>.