Skip to content
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

Conversation

MaineC
Copy link

@MaineC MaineC commented May 21, 2015

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.

@MaineC MaineC self-assigned this May 21, 2015
@MaineC MaineC force-pushed the feature/simple-query-string-refactoring branch 3 times, most recently from 437b01b to 3b575fd Compare May 22, 2015 08:52
@Override
public Query toQuery(QueryParseContext parseContext) {
// Query text is required
if (queryText == null) {
Copy link
Member

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

@javanna
Copy link
Member

javanna commented May 26, 2015

done first round of review, left some comments.

@MaineC
Copy link
Author

MaineC commented May 28, 2015

I briefly chatted with @dakrone - here's his take on adding the Boostable interface:

I think the SimpleQueryString stuff could implement Boostable, the
reason it didn't previously I think was that it allowed specifying
fields in the ["field1", "field2"^2.0] syntax. We should add support for
the "boost" field that boosts the entire query to the syntax as well.

@MaineC MaineC force-pushed the feature/simple-query-string-refactoring branch 4 times, most recently from 89b3058 to b472e1e Compare June 3, 2015 08:03
* always sorted in same order for generated Lucene query for easier
* testing.
*/
private final Map<String, Float> fieldsAndWeights = new TreeMap<>();
Copy link
Member

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?

Copy link
Author

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.

Copy link
Member

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?

Copy link
Author

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} */
Copy link
Member

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

@javanna
Copy link
Member

javanna commented Jun 22, 2015

I did a last round of review, this is very close.

@MaineC
Copy link
Author

MaineC commented Jun 22, 2015

Will make the code changes tomorrow morning when awake - thanks for your comments. Will ping you when done.

@MaineC MaineC force-pushed the feature/simple-query-string-refactoring branch 2 times, most recently from 02a253c to 5246a59 Compare June 23, 2015 08:46
/** 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;
Copy link
Member

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

Copy link
Author

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:

#11274 (diff)

Copy link
Member

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?

Copy link
Author

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.

@javanna
Copy link
Member

javanna commented Jun 23, 2015

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
@MaineC MaineC force-pushed the feature/simple-query-string-refactoring branch from cc8df97 to e170c8e Compare June 23, 2015 19:26
MaineC pushed a commit that referenced this pull request Jun 23, 2015
…actoring

Refactors SimpleQueryStringBuilder/Parser
@MaineC MaineC merged commit 7afa37c into elastic:feature/query-refactoring Jun 23, 2015
@MaineC MaineC removed the review label Jun 23, 2015
MaineC pushed a commit that referenced this pull request Jun 24, 2015
Forgot to commit the very last change yesterday which led to analyzeWildcard to remain at the default value always.

Relates to #11274
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
…ing-refactoring

Refactors SimpleQueryStringBuilder/Parser
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
Forgot to commit the very last change yesterday which led to analyzeWildcard to remain at the default value always.

Relates to elastic#11274
MaineC pushed a commit that referenced this pull request Aug 20, 2015
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
@javanna
Copy link
Member

javanna commented Sep 1, 2015

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);
It breaks how we parse the locale on the REST layer, as we now do Locale#forLanguageTag and we output using Locale#toLanguageTag. This is more correct but not a backwards compatible change. Locales that were previously properly parsed might not get parsed anymore. See #13229.

@clintongormley clintongormley added :Search/Search Search-related issues that do not fall into other categories and removed :Query Refactoring labels Feb 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>breaking :Search/Search Search-related issues that do not fall into other categories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants