Refactors TermsQueryBuilder and Parser#12042
Conversation
There was a problem hiding this comment.
not a big fan of these two new methods to be honest. Maybe since they are needed in one query only we can loop there instead?
There was a problem hiding this comment.
not a big fan either, but note we do use convertToStringListIfBytesRefList in two places. So I moved them to the builder instead.
There was a problem hiding this comment.
so the alternative is looping in two places instead in TermsQueryBuilder? I think I would go for that.
|
I did a first review, can you please rebase and address comments? Also, I would like to know from @s1monw and @jpountz what they think about having a Client within IndexQueryParseService, like we are adding here, so that we can retrieve it through QueryShardContext and execute the needed get calls (still on the data node). Wonder if there's any other/better way, I couldn't come up with any. |
|
@javanna Thanks for the review. Just a couple of notes here.
I think we should only document the change in migrate doc for 2) and 3) |
0815151 to
671e7c7
Compare
|
@javanna rebased and addressed comments. We should still figure out how best to mock a handleTermsLookup or a Client in our test. This will also be useful for queries such as MLT. Thanks for the review. |
671e7c7 to
3651c99
Compare
There was a problem hiding this comment.
I think this is ok used this way, @cbuescher do you agree ?
There was a problem hiding this comment.
I think this is ok, the isFilter() flag should be set when parent queries that are already using toQuery() produce some inner query in a filter context.
There was a problem hiding this comment.
cool then remove the NOCOMMIT here?
There was a problem hiding this comment.
Same here as above, since both methods are related and read similar.
|
This is much closer now I did another round of review and left some comments |
There was a problem hiding this comment.
can we add a test that verifies that if you specify both terms_lookup and values on the REST layer we get back a validation error? This part in the parser seems a bit tricky, I want to make sure we don't lose this.
b92d0c3 to
9b8eef6
Compare
|
@javanna I addressed all the comments. Hopefully it should be good to go. Thank you for the review. |
|
I did a last review round, left some minor comments. LGTM otherwise |
There was a problem hiding this comment.
last super small comment, can we remove the get prefix from these setters from now, for consistency reasons?
There was a problem hiding this comment.
I'd like to but it would break bwc. Mark them as deprecated?
There was a problem hiding this comment.
it doesn't break anything given that this class was only used internally, it was not part of the java api. Only this change makes it part of the java api.
|
left one tiny comment, LGTM though |
Refactors TermsQueryBuilder and Parser for elastic#10217. This PR is against the query-refactoring branch. Closes elastic#12042
7f3d530 to
1af0a39
Compare
Refactors TermsQueryBuilder and Parser for #10217. Also removes deprecated
TermsLookupQuery class and unused or deprecated options
execution,min_should_match,lookup_cache.This PR is against the query-refactoring branch.