Clarify what query components cross_fields supports #68795
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
|
This refactor isn't high priority on its own, since we don't touch |
jtibshirani
commented
Feb 10, 2021
| @@ -184,15 +205,7 @@ protected Query newTermQuery(Term term, float boost) { | |||
|
|
|||
| @Override | |||
| protected Query newPrefixQuery(Term term) { | |||
There was a problem hiding this comment.
A couple notes:
- Although the
cross_fieldsquery doesn't allow phrases, theanalyzePhrasemethod must be implemented to support multi-word synonyms withauto_generate_synonyms_phrase_query: true. - I think we can remove
analyzeMultiPhrase. This method supports phrase queries that contain a term with synonyms, which should never occur withcross_fields. I opted not to remove it since the logic is tricky and I didn't want to risk a regression when we aim to deprecatecross_fieldsanyways.
jtibshirani
added
:Search/Search
|
Pinging @elastic/es-search (Team:Search) |
jtibshirani
added a commit
that referenced
this pull request
Aug 23, 2021
When backporting #68795, we introduced a regression around `match` queries on field aliases. If the `match` query parses to a `synonym` query (because its analyzer can produce multiple tokens at a single position), then we don't resolve the field alias to its concrete field. This means the query will not have any results. We already had a test for this case but it was too narrow. Note this regression only affects 7.x, there is no bug on master.
jtibshirani
added a commit
that referenced
this pull request
Aug 23, 2021
When backporting #68795, we introduced a regression around `match` queries on field aliases. If the `match` query parses to a `synonym` query (because its analyzer can produce multiple tokens at a single position), then we don't resolve the field alias to its concrete field. This means the query will not have any results. We already had a test for this case but it was too narrow. Note this regression only affects 7.x, there is no bug on master.
jtibshirani
added a commit
that referenced
this pull request
Aug 23, 2021
When backporting #68795, we introduced a regression around `match` queries on field aliases. If the `match` query parses to a `synonym` query (because its analyzer can produce multiple tokens at a single position), then we don't resolve the field alias to its concrete field. This means the query will not have any results. We already had a test for this case but it was too narrow. Note this regression only affects 7.x, there is no bug on master.
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.
The parsing logic for the
cross_fieldsmode was very general, making it hardto tell what query components it actually supports. This PR clarifies that only
'bag of words' queries are supported, it does not accept phrase or prefix
queries. It also renames
BlendedQueryBuilder->CrossFieldsQueryBuilderforclarity.