Change HLRC count request to accept a QueryBuilder #46904
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
Currently the CountRequest accepts a search source builder, while the RestCountAction only accepts a top level query object. This can lead to confusion if another element (e.g. aggregations) is specified, because that will be ignored on the server side in RestCountAction. By deprecating the current setter & constructor that accept a SearchSourceBuilder and adding replacement that accepts a QueryBuilder it is clear what the count api can handle from HLRC side. Follow up from elastic#46829
Collaborator
|
Pinging @elastic/es-core-features |
martijnvg
changed the title
jimczi
reviewed
Sep 20, 2019
Contributor
jimczi
left a comment
jimczi
left a comment
There was a problem hiding this comment.
I left some minor comments, RequestConverters#count could also use the countRequest directly to serialize the body since CountRequest now implements ToXContentObject ?
| } | ||
|
|
||
| /** | ||
| * @return The provided the query to execute with the count request or |
Contributor
There was a problem hiding this comment.
nit: s/The provided the query/The provided query/
| Objects.equals(routing, that.routing) && | ||
| Objects.equals(preference, that.preference); | ||
| Objects.equals(preference, that.preference) && | ||
| Objects.equals(terminateAfter, that.terminateAfter) && |
| public CountRequest(String[] indices, SearchSourceBuilder searchSourceBuilder) { | ||
| indices(indices); | ||
| this.searchSourceBuilder = searchSourceBuilder; | ||
| this.query = searchSourceBuilder.query(); |
Contributor
There was a problem hiding this comment.
Should we handle a null SearchSourceBuilder ? I guess that it is allowed today.
Member
Author
Yes, I forgot that. I've pushed a new commit that addresses that and the other comments. |
martijnvg
added a commit
that referenced
this pull request
Sep 23, 2019
Currently the CountRequest accepts a search source builder, while the RestCountAction only accepts a top level query object. This can lead to confusion if another element (e.g. aggregations) is specified, because that will be ignored on the server side in RestCountAction. By deprecating the current setter & constructor that accept a SearchSourceBuilder and adding replacement that accepts a QueryBuilder it is clear what the count api can handle from HLRC side. Follow up from #46829
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Currently the CountRequest accepts a search source builder, while the
RestCountAction only accepts a top level query object. This can lead
to confusion if another element (e.g. aggregations) is specified,
because that will be ignored on the server side in RestCountAction.
By deprecating the current setter & constructor that accept a
SearchSourceBuilder instance and adding replacement that
accepts a QueryBuilder instance it is clear what the count api
can handle from the HLRC side.
Follow up from #46829