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 PrefixQuery #12032

Conversation

alexksikes
Copy link
Contributor

Relates to #10217

This PR is against the query-refactoring branch.


@Override
protected PrefixQueryBuilder doCreateTestQueryBuilder() {
PrefixQueryBuilder query = newRandomQueryBuilder();
Copy link
Member

Choose a reason for hiding this comment

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

out of curiosity, why do we have a newRandomQueryBuilder method here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was actually thinking that this could later be moved as a helper method in the BaseQueryTestCase class, something that returns a random field name together with its value.

Copy link
Member

Choose a reason for hiding this comment

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

ah ok I see

@javanna
Copy link
Member

javanna commented Jul 6, 2015

left a couple of small comments

protected void doWriteTo(StreamOutput out) throws IOException {
out.writeString(fieldName);
out.writeGenericValue(value);
out.writeOptionalString(fieldName);
Copy link
Member

Choose a reason for hiding this comment

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

Should this be rewrite field instead of fieldName (mentioned twice)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks good catch!

@alexksikes
Copy link
Contributor Author

@javanna @cbuescher Thanks for the review. I updated the PR accordingly.

@javanna
Copy link
Member

javanna commented Jul 8, 2015

looks good to me, @cbuescher can you have a final look plese?

}
value = randomDate();
break;
default:
Copy link
Member

Choose a reason for hiding this comment

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

This can't happen, and if for some reason after the switch fielname/value are unassigned the returned query will throw exceptions at some point (validation, doXContent, toQuery), so given this is a test method I'd remove it.

@cbuescher
Copy link
Member

Did another round of reviews, left just two question/comments regarding setup of test query, otherwise looks good.

alexksikes added a commit to alexksikes/elasticsearch that referenced this pull request Jul 8, 2015
The parser takes an Object value, so should the builder.

Relates to elastic#12032
@alexksikes alexksikes force-pushed the feature/query-refactoring-prefix branch 2 times, most recently from b882a2d to 0aaac85 Compare July 9, 2015 09:04
@alexksikes
Copy link
Contributor Author

@javanna @cbuescher Thanks for the review. I rebased the PR and updated it.

}

@Override
public QueryValidationException validate() {
Copy link
Member

Choose a reason for hiding this comment

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

Could also reuse the BaseTermQueryBuilder#validate here? I realize we agreed on always overwriting this for the AbstractQueryBuilder, but since this just repeats the super types implementation, maybe we should call it?

Copy link
Member

Choose a reason for hiding this comment

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

+1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

definitely! +1

@javanna
Copy link
Member

javanna commented Jul 9, 2015

left a couple of minor comments, I would wait for #12124 (or corresponding adapted PR) before getting this in though.


import static org.hamcrest.Matchers.is;

public class PrefixQueryBuilderTest extends BaseQueryTestCase<PrefixQueryBuilder> {
Copy link
Member

Choose a reason for hiding this comment

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

I don't know if it's possible to also extend the generic BaseTermQueryTestCase here, since a lot of the setup looks similar. That one is also testing Boolean as a value type while this test adds Date there. Maybe the creation of the expected query gets a bit too complicated, but the two existing Test classes (SpanTermQueryBuilderTest, TermQueryBuilderTest) are quiet small that way. Might be worth looking into merging, unless you already tried and found it to hard to read afterwards.

Copy link
Member

Choose a reason for hiding this comment

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

Patially revoking my last comment, I would only try this and add the inheritance level in the test if in the end you decide to have PrefixQueryBuilder extend BaseTermQueryBuilder. Thinking about it a bit more, I'm not sure if this is maybe growing to complex at this point and a bit of code duplication should be traded for ease of understanding.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

+1 for using BaseTermQueryTestCase

Copy link
Member

Choose a reason for hiding this comment

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

if PrefixQueryBuilder won't extend BaseTermQueryBuilder anymore I think we can't extend BaseTermQueryTestCase either here

Copy link
Member

Choose a reason for hiding this comment

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

It might be possible, but I would try to avoid it in this case. I would go for either using both BaseTerm classes or none.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK then we go for none? I am ok either way.

Copy link
Member

Choose a reason for hiding this comment

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

I would leave it as-is, it needs to extend BaseQueryTestCase

@cbuescher
Copy link
Member

Also did another round and left a couple of comments.

@alexksikes alexksikes force-pushed the feature/query-refactoring-prefix branch from 0aaac85 to 4997b9e Compare July 13, 2015 12:40
alexksikes added a commit to alexksikes/elasticsearch that referenced this pull request Jul 13, 2015
@alexksikes
Copy link
Contributor Author

@javanna Thanks for the review. I rebased and updated the PR accordingly.

return Objects.equals(fieldName, other.fieldName) &&
Objects.equals(value, other.value);
}

@Override
protected final QB doReadFrom(StreamInput in) 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.

we can revert these two changes no given that we dont' extend from this class anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think we should allow these to be overridden, but I'm happy to make the change.

Copy link
Member

Choose a reason for hiding this comment

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

well we don't need to extend this anywhere, plus these changes don't have anything to do with this PR at this point, would prefer to leave them out.

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 revert this change.

@alexksikes
Copy link
Contributor Author

@javanna Thanks for the review. We need to address #11865 (comment) before it can be pushed though, and waiting on #12204 as well.

alexksikes added a commit that referenced this pull request Jul 16, 2015
Relates to elastic#10217
Closes elastic#12032

This PR is against the query-refactoring branch.
@alexksikes alexksikes force-pushed the feature/query-refactoring-prefix branch from 8a75083 to 37c6347 Compare July 24, 2015 09:48
@alexksikes
Copy link
Contributor Author

@javanna it's rebased, you can take a look. Thank you.

@javanna
Copy link
Member

javanna commented Jul 24, 2015

LGTM

@alexksikes alexksikes merged commit 37c6347 into elastic:feature/query-refactoring Jul 24, 2015
@alexksikes alexksikes deleted the feature/query-refactoring-prefix branch July 24, 2015 10:06
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
Relates to elastic#10217
Closes elastic#12032

This PR is against the query-refactoring branch.
@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