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

BoolQueryBuilder uses ObjectParser #52880

Merged
merged 5 commits into from Mar 4, 2020

Conversation

romseygeek
Copy link
Contributor

This commit removes the hand-rolled x-content parsing logic from BoolQueryBuilder
and instead uses an ObjectParser to handle parsing. It also removes the long-deprecated
(since version 6) disable_coord parameter.

@romseygeek romseygeek added :Search/Search Search-related issues that do not fall into other categories >refactoring v8.0.0 v7.7.0 labels Feb 27, 2020
@romseygeek romseygeek self-assigned this Feb 27, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (:Search/Search)

@romseygeek
Copy link
Contributor Author

There's also a TODO here regarding mustNot vs must_not; it's trivial now to deprecate the former in favour of the latter, and I think it's worth doing that given our motto of 'leniency is abhorrent and should be eschewed'.

private static final String MUST = "must";
private static final ParseField DISABLE_COORD_FIELD = new ParseField("disable_coord")
.withAllDeprecated("disable_coord has been removed");
private static final ParseField MUSTNOT = new ParseField("mustNot"); // TODO deprecate?
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 so!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'll do this in a followup to get more eyes on it.

ParsingException ex = expectThrows(ParsingException.class, () -> parseQuery(query));
assertEquals("unknown query [unknown_query]", ex.getMessage());
XContentParseException ex = expectThrows(XContentParseException.class, () -> parseQuery(query));
assertEquals("[1:41] [bool] failed to parse field [must]", ex.getMessage());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth asserting on the "inner" exception too. Or something. Because this message isn't nearly a nice as the other one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++ I pushed f0f9b15

@romseygeek
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/2

1 similar comment
@romseygeek
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/2

@romseygeek
Copy link
Contributor Author

@elasticmachine update branch

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@romseygeek romseygeek merged commit 0edb1d3 into elastic:master Mar 4, 2020
romseygeek added a commit that referenced this pull request Mar 4, 2020
This commit removes the hand-rolled x-content parsing logic from BoolQueryBuilder
and instead uses an ObjectParser to handle parsing. It also removes the long-deprecated
(since version 6) disable_coord parameter.
@jamshid
Copy link

jamshid commented Sep 9, 2020

I know it's been deprecated since 6 but it seems bad practice to have removed it in a 7.x patch rather than waiting for 8.0. This change breaks working clients and prevents the server from being upgraded from 7.5.2 => 7.7.0.

@nik9000
Copy link
Member

nik9000 commented Sep 9, 2020

I know it's been deprecated since 6 but it seems bad practice to have removed it in a 7.x patch rather than waiting for 8.0. This change breaks working clients and prevents the server from being upgraded from 7.5.2 => 7.7.0.

Your right. @romseygeek, I think we should have only applied the removal to master. I think it might be a bit late now though.

@jamshid
Copy link

jamshid commented Sep 10, 2020

Thanks, yes probably too late now.
Counterpoint: Elasticsearch releases are rapid and upgrading is often costly because of required changes, so maybe there are more users who just haven't upgraded in past few months and will break because disable_coord was removed.
But idk.
Ok I'll figure out if I can workaround this change or do without the _cat api fix #42725.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>refactoring :Search/Search Search-related issues that do not fall into other categories v7.7.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants