Skip to content

Conversation

MaineC
Copy link

@MaineC MaineC commented May 6, 2015

Refactors SpanTermQueryBuilder analogous to TermQueryBuilder. Factors common code between the two into separate classes.

Relates to #10217

This goes against the feature/query-refactoring branch.

public SpanTermQueryBuilder queryName(String queryName) {
this.queryName = queryName;
return this;
}

/** {@inheritDoc} */
@Override
public void doXContent(XContentBuilder builder, Params params) throws IOException {
builder.startObject(SpanTermQueryParser.NAME);
Copy link
Member

Choose a reason for hiding this comment

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

Not sure, but if we use parserName() instead of the constant here, can we move the whole doXContent method do the BaseTermQueryBuilder?

Copy link
Author

Choose a reason for hiding this comment

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

Good point. Will check.

@MaineC MaineC force-pushed the feature/span-term-query-refactoring branch from e20b6b4 to 24d7ae5 Compare May 7, 2015 07:32
private static IndexQueryParserService queryParserService;
private static Index index;
protected static IndexQueryParserService queryParserService;
protected static Index index;
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 those two can stay private, or do you need them in the concrete test classes? They should also be accesible via the context you get from createContext() if you need them.

Copy link
Author

Choose a reason for hiding this comment

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

This must have been a merge artifact - will revert, thanks for spotting this.

@cbuescher
Copy link
Member

Left some super minor comments, I like the way the similarities in TermQuery and SpanTermQuery are factored out here but still I'd like to hear what @javanna or @dakrone think about this, especially the use of generics.

@MaineC
Copy link
Author

MaineC commented May 8, 2015

@cbuescher Thanks for your comments - changed the code accordingly.

@cbuescher
Copy link
Member

Thanks, LGTM, but lets see if anybody else has an opinion.

/*
* Added class name to the hashcode so a {@link SpanTermQueryBuilder} and a {@link TermQueryBuilder} aren't considered the same
* if they have the same parameters set.
*/
Copy link
Member

Choose a reason for hiding this comment

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

this makes sense, wonder if the comment is even needed, seems more like a commit message ;)

@javanna
Copy link
Member

javanna commented May 8, 2015

left some comments

@MaineC MaineC force-pushed the feature/span-term-query-refactoring branch from 8908571 to da2eb5a Compare May 11, 2015 09:46
@MaineC
Copy link
Author

MaineC commented May 11, 2015

@javanna Thanks for your comments. Tried to incorporate them in the changes.

}

/** Writes the given parameters. */
public void writeTo(StreamOutput out) throws IOException {
Copy link
Member

Choose a reason for hiding this comment

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

missing @Override?

@MaineC MaineC force-pushed the feature/span-term-query-refactoring branch from 560ea69 to beab4c1 Compare May 12, 2015 08:41
* @param fieldName The name of the field
* @param value The value of the term
*/
@SuppressWarnings("boxing")
Copy link
Author

Choose a reason for hiding this comment

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

Added this after enabling (un-)boxing warnings. Let me know if this is too paranoid.

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 it is :) especially given that we don't suppress this type of warnings anywhere in our codebase, not sure we should introduce this here. We tend to suppress stuff around generics mainly, in general warnings that show up with default IDE's setup (which IDE? :P )

@javanna
Copy link
Member

javanna commented May 13, 2015

left a very minor comment, LGTM though, please push ;)

@MaineC MaineC force-pushed the feature/span-term-query-refactoring branch 2 times, most recently from e5a1e63 to 5150237 Compare May 18, 2015 07:39
Isabel Drost-Fromm added 2 commits May 18, 2015 09:45
This attempts to do to SpanTermQueryBuilder what has already been changed for TermQueryBuilder. The commit tries to avoid code duplication where possible by pulling what is the same for both QueryBuilders and tests into separate classes.

Relates to elastic#10217
One final refactoring of the SpanTermQuery - makes sure the class hierarchy works again.

Relates to elastic#10217
@MaineC MaineC force-pushed the feature/span-term-query-refactoring branch from 5150237 to 7a7c7f4 Compare May 18, 2015 07:47
MaineC pushed a commit that referenced this pull request May 18, 2015
…ring

Refactors SpanTermQueryBuilder.

Due to similarities with TermQueryBuilder a lot of code was moved into separate abstract classes that can be used by both - TermQueryBuilder and SpanTermQueryBuilder.

Relates to #10217
@MaineC MaineC merged commit 87d1bdd into elastic:feature/query-refactoring May 18, 2015
@MaineC MaineC removed the review label May 18, 2015
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
…refactoring

Refactors SpanTermQueryBuilder.

Due to similarities with TermQueryBuilder a lot of code was moved into separate abstract classes that can be used by both - TermQueryBuilder and SpanTermQueryBuilder.

Relates to elastic#10217
@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