Refactors WrapperQueryBuilder and Parser#12037
Conversation
|
left some comments |
|
@javanna Thanks for the review. I updated the PR. |
There was a problem hiding this comment.
See the comment I added to the original discussion on the outdated diff.
|
Added some comments. |
|
@MaineC Thanks I have addressed your comment. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
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. |
There was a problem hiding this comment.
//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.
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.
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.
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. |
|
did another round, left a few comments |
|
@javanna comments addressed. Thanks for the review. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.