-
Notifications
You must be signed in to change notification settings - Fork 25k
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 WrapperQueryBuilder and Parser #12037
Refactors WrapperQueryBuilder and Parser #12037
Conversation
* Creates a query builder given a query provided as a {@link BytesReference} | ||
*/ | ||
public WrapperQueryBuilder(BytesReference source) { | ||
this.source = source.array(); | ||
this.source = source.toBytes(); |
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.
why was this changed?
left some comments |
@javanna Thanks for the review. I updated the PR. |
} | ||
|
||
@Override | ||
protected void doXContent(XContentBuilder builder, Params params) throws IOException { | ||
builder.startObject(NAME); | ||
builder.field("query", source, offset, length); | ||
builder.field("query", source); |
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.
See the comment I added to the original discussion on the outdated diff.
Added some comments. |
@MaineC Thanks I have addressed your comment. |
private final int offset; | ||
private final int length; | ||
static final WrapperQueryBuilder PROTOTYPE = new WrapperQueryBuilder(null, -1, -1); | ||
static final WrapperQueryBuilder PROTOTYPE = new WrapperQueryBuilder(new byte[0]); |
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.
we can just pass in null here?
04080fe
to
fb61ce8
Compare
@javanna I addressed the comments and rebased. You can take a look. Thank you. |
@@ -138,6 +138,9 @@ In addition some query builders have been removed or renamed: | |||
* `filtered(...)` removed. Use `filteredQuery(...)` instead. | |||
* `inQuery(...)` removed. | |||
|
|||
Also QueryBuilders.WrapperQueryBuilder(byte[] source, int offset, int length) has been removed, |
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.
the method names start with a lowercase w
. Shouldn't we have both changes here? QueryBuilders and WrapperQueryBuilder constructor? those are both public.
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.
sure I'll make that change
I did another round, left some comments, also we need some discussion on when we effectively parse the binary query here... |
fb61ce8
to
d6687d2
Compare
@javanna I rebased it to incorporate the latest changes. Something I had to do is move supportsBoostAndQueryName() method to AbstractQueryBuilder. Please see comment in code. Thank you. |
*/ | ||
//norelease this has to be put in here because of the call on toQuery which would override the boost and queryName | ||
//norelease of the wrapped query with defaults | ||
protected boolean supportsBoostAndQueryName() { |
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.
//norelease is used for code that can be removed later on in the refactoring. I don't think it should be used here, or at least I don't see how we can remove this method if we introduce it here. The idea for supportsBoostAndQueryName
was to be only a test method to "mark" few exceptional queries, it wasn't meant to be moved to prod code ever.
The reason why you did this is because the wrapped query has its own boost that gets overwritten by the default 1.0f boost of the outer query. I tend to think that this is more a test problem, and the doAssertLuceneQuery in WrapperQueryBuilderTest should be adjusted. Maybe there are other ways or ideas, but we should not move this supportsBoostAndQueryName
to prod code I think.
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.
AbstractQueryBuilder#toQuery does set a boost unless it is disabled. If I remember correctly I think that was the idea of being to disable boost as part of the actual query builder, not just in the test.
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 am on the fence on this. We have one query with boost: 2.0
which holds an inner query with boost: 3.0
. Let's say that the final lucene query will be the lucene representation of the inner query. What about the final boost, should it be 2.0 or 3.0? Right now the boost set on the main query overrides the inner boost. I am not sure if this is the right behaviour, which would simply require to adjust the doAssertLuceneQuery here to take this behaviour into account. But supportsBoostAnQueryName
should not be moved to prod code. I would go back to having it in test and I would adjust the doAssertLuceneQuery here to work properly without needing to disable anything. Then we can open an issue and discuss what the final boost should be.
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 see that you moved back to supportsBoostAndQueryName in BaseQUeryTestCase. The way you do it now makes perfect sense.
I had a look, left a comment, thinking more about it this query will give us headache, especially in relation to #12527. This is the only query that needs a |
@alexksikes could you please rebase and address comments? |
d6687d2
to
328f7b4
Compare
@javanna I rebased and addressed the comments. Thanks for the review. |
@Override | ||
protected boolean supportsBoostAndQueryName() { | ||
return false; | ||
} |
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.
why was this removed?
did another round, left a few comments |
@javanna comments addressed. Thanks for the review. |
parseContext.reset(qSourceParser); | ||
Query expected = parseContext.parseInnerQueryBuilder().toQuery(context); | ||
if (expected != null) { | ||
expected.setBoost(queryBuilder.boost()); |
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.
can you replace with expected.setBoost(AbstractQueryBuilder.DEFAULT_BOOST)
for clarity? I will also open up an issue for discussion on this boost matter.
I did a final round, one old comment on parsing wasn't addressed yet, plus left a minor comment on testing. |
49e193e
to
c1cc5f4
Compare
@javanna addressed the comments and rebased. Thanks for the review. |
parser.nextToken(); | ||
|
||
if (source == null) { | ||
throw new QueryParsingException(parseContext, "wrapper query has no [source] specified"); |
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 the field name should be query
in the error message
LGTM besides the tiny comment I left |
Relates to elastic#10217 Closes elastic#12037 This PR is against the query-refactoring branch.
c1cc5f4
to
afcbd29
Compare
Relates to elastic#10217 Closes elastic#12037 This PR is against the query-refactoring branch.
This change is breaking for the java API as it removes the |
Relates to #10217
This PR is against the query-refactoring branch.