Unify query_string parameters parsing #11057
Merged
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
javanna
added
>enhancement
v2.0.0-beta1
review
:Core/Infra/REST API
|
LGTM in general, but we may need to adapt the rest spec and add tests for the new APIs supporting the parameters? |
|
Thanks @spinscale I pushed a new commit. Updated REST spec (including parameters that were already support but not listed) and added REST tests. Tests were completely missing for count api and search_exists, so I added some basic generic tests too. |
|
nice, ++ for more tests LGTM |
There currently are small differences between search api and count, exists, validate query, explain api when it comes to reading query_string parameters. `analyze_wildcard`, `lowercase_expanded_terms` and `lenient` are only read by the search api and ignored by all other mentioned apis. Unified code to fix this and make sure it doesn't happen again. Also shared some code when it comes to printing out the query as part of SearchSourceBuilder conversion to ToXContent. Extended REST spec to include all the supported params (some that were already supported weren't listed), and added REST tests (also some basic tests for count and search_exists which weren't tested at all). Closes elastic#11057
javanna
force-pushed
the
enhancement/unify_query_string_search
branch
from
c74dc9a
to
d7e585c
Compare
javanna
added a commit
to javanna/elasticsearch
that referenced
this pull request
May 11, 2015
There currently are small differences between search api and count, exists, validate query, explain api when it comes to reading query_string parameters. `analyze_wildcard`, `lowercase_expanded_terms` and `lenient` are only read by the search api and ignored by all other mentioned apis. Unified code to fix this and make sure it doesn't happen again. Also shared some code when it comes to printing out the query as part of SearchSourceBuilder conversion to ToXContent. Extended REST spec to include all the supported params (some that were already supported weren't listed), and added REST tests (also some basic tests for count and search_exists which weren't tested at all). Closes elastic#11057
javanna
added a commit
that referenced
this pull request
May 11, 2015
…search & validate_query relates to #11057
javanna
added a commit
that referenced
this pull request
May 11, 2015
…search & validate_query relates to #11057
karmi
added a commit
to elastic/elasticsearch-ruby
that referenced
this pull request
May 13, 2015
clintongormley
changed the title
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.
There currently are small differences between search api and count, exists, validate query, explain api when it comes to reading query_string parameters.
analyze_wildcard,lowercase_expanded_termsandlenientare only read by the search api and ignored by all other mentioned apis. Unified code to fix this and make sure it doesn't happen again. Also shared some code when it comes to printing out the query as part of SearchSourceBuilder conversion to ToXContent.