Skip to content

Conversation

cbuescher
Copy link
Member

Moving the query building functionality from the parser to the builders
new toQuery() method analogous to other recent query refactorings.

Relates to #10217

PR goes against the query-refactoring branch

Moving the query building functionality from the parser to the builders
new toQuery() method analogous to other recent query refactorings.

Relates to elastic#10217
@cbuescher
Copy link
Member Author

The changes include minor updates to AndQueryBuilder as well that I just discoverd. In fact, the two queries are so closely related that I was thinking about factoring out a common parent class, but since they are both deprecated and there are just two cases that could be grouped under that parent class I didn't do that just yet. Open to suggestions on this part though.


BooleanQuery query = new BooleanQuery();
for (QueryBuilder f : filters) {
query.add(f.toQuery(parseContext), Occur.SHOULD);
Copy link
Member

Choose a reason for hiding this comment

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

what happens when toQuery returns null here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch, just copied that part of the code but know we have this extra step. I think if can return null. This is anoying, maybe at some point we can revisit this and see if instead of passing up null up through the whole query-tree we can have some sort of No-Op Query Builder and maybe an equivalent as a lucene query. Just a thought, will just catch this here.

Copy link
Member

Choose a reason for hiding this comment

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

but what did we do before when parse returned null? should be the same? maybe it is simply allowed to pass in null here if we used to do it already?

Copy link
Member Author

Choose a reason for hiding this comment

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

That case is already handled in the parser, I think. Will double check, also in AndQB.

Copy link
Member Author

Choose a reason for hiding this comment

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

Can confirm this, if in the parser innerParser returns null, it's not added to the list of QueryBuilders we use. That logic is already in the parser code.

@javanna
Copy link
Member

javanna commented Jun 23, 2015

LGTM besides the small comment I left. Regarding similarities with and query builder, I think I would keep everything as-is, otherwise we would complicate the class hierarchy even more which is probably not worth it for deprecated classes

@javanna
Copy link
Member

javanna commented Jun 23, 2015

LGTM

cbuescher added a commit that referenced this pull request Jun 23, 2015
Query refactoring: OrQueryBuilder and Parser
@cbuescher cbuescher merged commit fdc4d01 into elastic:feature/query-refactoring Jun 23, 2015
@kevinkluge kevinkluge removed the review label Jun 23, 2015
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
…ring-or

Query refactoring: OrQueryBuilder and Parser
@cbuescher cbuescher deleted the feature/query-refactoring-or branch March 31, 2016 09:26
@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
: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.

4 participants