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

Refactor MatchAllQueryBuilder, TermQueryBuilder, IdsQueryBuilder #10454

Conversation

cbuescher
Copy link
Member

MatchAllQueryBuilder, TermQueryBuilder, IdsQueryBuilder now include the fromXContent, doXContent and toQuery methods suggested in #9901. Also implementing the Streamable interface and adding unit tests for the serialization and parsing.

NOTE: this PR is against the feature/query-parse-refactoring branch.

context = new QueryParseContext(index, queryParserService);
testQuery = createTestQuery();
String contentString = createXContent(testQuery).string();
parser = XContentFactory.xContent(contentString).createParser(contentString);
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe it would be easier to extend ElasticsearchSingleNodeTest so that all these bindings are already done for you?

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, I thought it nicer to have unit tests here than having to do the whole node setup. I'll try this, but how expensive is the setup of the ElasticsearchSingleNodeTest?
If we write more query tests like this I, an alternative would be to have an own BaseTest class for this. Already suggested this to Lee.

@javanna
Copy link
Member

javanna commented Apr 10, 2015

I left a bunch of comments. I am pretty positive that we can trim down the code needed for testing, by just having a base test class with a few abstract methods that provide the query to test etc. we'll see how far we can take this. I am happy that we are going with unit testing rather than requiring to fire up a node.

My personal preference, I think a single PR per query would be easier to review, also then you don't have to adapt all of the other queries to the same comments :) but I see how this time it was better to touch a few of them rather than just one.

@@ -88,6 +94,10 @@ public IdsQueryBuilder boost(float boost) {
return this;
}

public float getBoost() {
Copy link
Member

Choose a reason for hiding this comment

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

one more thing, these are going to be user facing public methods, we should add javadocs for each of them

@cbuescher
Copy link
Member Author

I worked through your comments. When we got through the other PR with Lees query we can start identifying common issues and test setup that can be generalised. I'll wait with further improvements here till we decided what kind of Parser/Builder merge we want on the feature branch and if we have to rebase there.

@javanna
Copy link
Member

javanna commented Apr 20, 2015

This got replaced by individual PRs, one per query: #10668 , #10669 & #10670 . Closing.

@javanna javanna closed this Apr 20, 2015
@kevinkluge kevinkluge removed the review label Apr 20, 2015
@clintongormley clintongormley added :Search/Search Search-related issues that do not fall into other categories and removed :Query Refactoring labels Feb 14, 2018
@cbuescher cbuescher deleted the feature/qpr-matchall-terms branch March 20, 2024 20:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
: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