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 WrapperQueryBuilder and Parser #12037

Conversation

alexksikes
Copy link
Contributor

Relates to #10217

This PR is against the query-refactoring branch.

* Creates a query builder given a query provided as a {@link BytesReference}
*/
public WrapperQueryBuilder(BytesReference source) {
this.source = source.array();
this.source = source.toBytes();
Copy link
Member

Choose a reason for hiding this comment

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

why was this changed?

@javanna
Copy link
Member

javanna commented Jul 6, 2015

left some comments

@alexksikes
Copy link
Contributor Author

@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);
Copy link

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.

@MaineC
Copy link

MaineC commented Jul 14, 2015

Added some comments.

@alexksikes
Copy link
Contributor Author

@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]);
Copy link
Member

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?

@alexksikes alexksikes force-pushed the feature/query-refactoring-wrapper-query branch from 04080fe to fb61ce8 Compare July 24, 2015 14:58
@alexksikes
Copy link
Contributor Author

@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,
Copy link
Member

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.

Copy link
Contributor Author

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

@javanna
Copy link
Member

javanna commented Jul 24, 2015

I did another round, left some comments, also we need some discussion on when we effectively parse the binary query here...

@alexksikes alexksikes force-pushed the feature/query-refactoring-wrapper-query branch from fb61ce8 to d6687d2 Compare July 30, 2015 13:04
@alexksikes
Copy link
Contributor Author

@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() {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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.

@javanna
Copy link
Member

javanna commented Aug 4, 2015

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 QueryParseContext in toQuery, along with the QueryShardContext. We will need to discuss this with @cbuescher and see what we can do about it.

@javanna
Copy link
Member

javanna commented Aug 7, 2015

@alexksikes could you please rebase and address comments?

@alexksikes alexksikes force-pushed the feature/query-refactoring-wrapper-query branch from d6687d2 to 328f7b4 Compare August 11, 2015 15:45
@alexksikes
Copy link
Contributor Author

@javanna I rebased and addressed the comments. Thanks for the review.

@Override
protected boolean supportsBoostAndQueryName() {
return false;
}
Copy link
Member

Choose a reason for hiding this comment

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

why was this removed?

@javanna
Copy link
Member

javanna commented Aug 13, 2015

did another round, left a few comments

@alexksikes
Copy link
Contributor Author

@javanna comments addressed. Thanks for the review.

parseContext.reset(qSourceParser);
Query expected = parseContext.parseInnerQueryBuilder().toQuery(context);
if (expected != null) {
expected.setBoost(queryBuilder.boost());
Copy link
Member

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.

@javanna
Copy link
Member

javanna commented Aug 17, 2015

I did a final round, one old comment on parsing wasn't addressed yet, plus left a minor comment on testing.

@alexksikes alexksikes force-pushed the feature/query-refactoring-wrapper-query branch from 49e193e to c1cc5f4 Compare August 17, 2015 17:18
@alexksikes
Copy link
Contributor Author

@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");
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 the field name should be query in the error message

@javanna
Copy link
Member

javanna commented Aug 17, 2015

LGTM besides the tiny comment I left

Relates to elastic#10217
Closes elastic#12037

This PR is against the query-refactoring branch.
@alexksikes alexksikes force-pushed the feature/query-refactoring-wrapper-query branch from c1cc5f4 to afcbd29 Compare August 17, 2015 17:54
@alexksikes alexksikes merged commit afcbd29 into elastic:feature/query-refactoring Aug 17, 2015
@alexksikes alexksikes deleted the feature/query-refactoring-wrapper-query branch August 17, 2015 17:54
@alexksikes alexksikes restored the feature/query-refactoring-wrapper-query branch August 17, 2015 19:26
alexksikes added a commit to alexksikes/elasticsearch that referenced this pull request Aug 17, 2015
Relates to elastic#10217
Closes elastic#12037

This PR is against the query-refactoring branch.
@javanna javanna added >breaking and removed review labels Aug 28, 2015
@javanna
Copy link
Member

javanna commented Aug 28, 2015

This change is breaking for the java API as it removes the WrapperQueryBuilder(byte[] source, int offset, int length) constructor, use WrapperQueryBuilder(byte[] source) instead.

@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.

5 participants