-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Refactors SimpleQueryStringBuilder/Parser #11274
Refactors SimpleQueryStringBuilder/Parser #11274
Conversation
437b01b
to
3b575fd
Compare
@Override | ||
public Query toQuery(QueryParseContext parseContext) { | ||
// Query text is required | ||
if (queryText == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this check should be moved to the validate method I think
done first round of review, left some comments. |
I briefly chatted with @dakrone - here's his take on adding the Boostable interface:
|
89b3058
to
b472e1e
Compare
* always sorted in same order for generated Lucene query for easier | ||
* testing. | ||
*/ | ||
private final Map<String, Float> fieldsAndWeights = new TreeMap<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feels like having to use a treemap for better testing might not be a good idea, unless we really need it besides testing. I guess this has to do with comparing expected lucene query with the output of toQuery? Does the lucene equals rely on ordering?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is for comparing expected to generated lucene query. From reading the equals method of boolean queries the clauses end up in an ArrayList which is sensitive to ordering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like a bug in lucene: https://issues.apache.org/jira/browse/LUCENE-6305 can you put a comment so that we know why and we get back to it once we fix the bug in lucene please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pointer. Sure - will add a comment.
return Objects.hash(fieldsAndWeights, analyzer, defaultOperator, queryText, queryName, minimumShouldMatch, settings); | ||
} | ||
|
||
/** {@inheritDoc} */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's not needed
I did a last round of review, this is very close. |
Will make the code changes tomorrow morning when awake - thanks for your comments. Will ping you when done. |
02a253c
to
5246a59
Compare
/** Specifies whether lenient query parsing should be used. */ | ||
private Boolean lenient = SimpleQueryStringBuilder.DEFAULT_LENIENT; | ||
/** Specifies whether wildcards should be analyzed. */ | ||
private Boolean analyzeWildcard = SimpleQueryStringBuilder.DEFAULT_ANALYZE_WILDCARD; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these Booleans can stay boolean primitive types? we now have the public constants for defaults, I think thats good enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Than I need to re-add the null-check there:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for the confusion. we shouldn't need null checks if we use boolean everywhere for these members? Just initialize them in the parser with their default values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah - that's what you meant. Sure, makes sense.
LGTM squash and push? ;) |
This commit makes SimpleQueryStringBuilder streamable, add hashCode and equals. Adds a dedicated builder/parser unit test, fixes formatting, adds JavaDoc where needed, adjust the handling of default values according to https://github.com/elastic/dev/blob/master/design/queries/general-guidelines.md Switched to using toLanguageTag/forLanguageTag when parsing Locales. Using LocaleUtils from either Elasticsearch or Apache commons resulted in Locales not passing the roundtrip test. For more info see https://issues.apache.org/jira/browse/LUCENE-4021 Relates to elastic#10217
cc8df97
to
e170c8e
Compare
…actoring Refactors SimpleQueryStringBuilder/Parser
Forgot to commit the very last change yesterday which led to analyzeWildcard to remain at the default value always. Relates to #11274
…ing-refactoring Refactors SimpleQueryStringBuilder/Parser
Forgot to commit the very last change yesterday which led to analyzeWildcard to remain at the default value always. Relates to elastic#11274
Brings Lucene query assertions to QB test. Theser assertions were originally added as part of the SimpleQueryStringQueryBuilder refactoring but removed later as there were more extensive tests in place already. This commit brings them back in as the other tests have been removed. This relates to #10217 and #11274
Marked this breaking. This PR contains a little breakage for the java api, as the SimpleQueryStringQueryBuilder#field(String) method doesn't allow to specify the boost in form field("field^2"). If you want to specify a boost you need to switch to SimpleQueryStringQueryBuilder#field(String, float) and do field("field", 2); |
Posting as early preview - in the current state makes SimpleQueryStringBuilder streamable, adds hashCode and equals. Next step adds Lucene query checks.
Note: Switched to using toLanguageTag/forLanguageTag when parsing Locales. Using LocaleUtils from either Elasticsearch or Apache commons resulted in Locales not passing the roundtrip test. For more info see https://issues.apache.org/jira/browse/LUCENE-4021 and the respective Java Locale.toString() documentation.
Relates to #10217
This PR goes against the feature/query-refactoring feature branch.