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
Refactoring of RegexpQuery #11896
Refactoring of RegexpQuery #11896
Conversation
heya @alexksikes sorry may I ask you to rebase please? #11974 changed things quite a bit, for the better! |
aa9bdfa
to
ba70a71
Compare
@javanna OK you can go ahead, it's rebased. Thank you. |
flags.add(flag); | ||
} | ||
} | ||
query.flags(randomFrom(flags)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this way you always a single flag. I think I would do something similar to what we do here: https://github.com/elastic/elasticsearch/blob/feature/query-refactoring/core/src/test/java/org/elasticsearch/index/query/SimpleQueryStringBuilderTest.java#L65
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what I wanted to do is generate arrays of unique flags. I'll fix this.
I did a first round of review, left a few comments |
|
||
@Test | ||
public void testValidate() { | ||
RegexpQueryBuilder commonTermsQueryBuilder = new RegexpQueryBuilder("", "regex"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename variable to regexpQueryBuilder?
left a few comments |
@javanna thanks for the review, I updated the PR. |
@@ -131,6 +132,7 @@ protected void configure() { | |||
String type = randomAsciiOfLengthBetween(1, 10); | |||
mapperService.merge(type, new CompressedXContent(PutMappingRequest.buildFromSimplifiedDef(type, | |||
DATE_FIELD_NAME, "type=date", | |||
DATE_FIELD_NAME_REGEX, "type=date,format=YYYY\\-MM", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
couldn't we re-use the existing date field that we already have?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i did try that but got failures when it gets to handle regex on dates. The accepted date format need all special regex parameters to be escaped, so the regex (here just a plain date) could be valid.
I did another round of review, maybe @cbuescher wants to have a quick look too? |
/** | ||
* Sets the regexp maxDeterminizedStates. | ||
*/ | ||
public RegexpQueryBuilder maxDeterminizedStates(int value) { | ||
this.maxDeterminizedStates = value; | ||
this.maxDetermizedStatesSet = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a bug previously? Seems so, just trying to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh boy I didn't spot this :) we should definitely backport this to master
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while refactoring some of the queries I did find quite a few bugs just like that. Should we always backport them to master? What's our overall policy on this matter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can answer for yourself at least for this one: would you be comfortable with 2.0 released with still this bug in it? Mayeb this fix should even be backported to 1.x, it's a bug and should be treated as such
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you ask me I'd be tempted to say that a bug is a bug and should definitely be backported. However, there are bugs which are only relevant in master, and so I thought that the query refactoring branch would be merged to master before 2.0 release. For this bug, I'll submit a fix for sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good! as for when we merge the branch...well we will do it when it's ready, most likely not before 2.0 but we don't know yet. One other thing about backporting fixes is that the branch is already big enough with the changes that we are making. If we can isolate non related fixes we simplify things a lot and clarify what happened when for the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
didn't you send a PR against master to fix this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it wasn't a bug: #12083
Did a quick round of review as well. Beeing late to the party, I first found the change from allowed regex in Builder from String to general Object confusing, also introducing much complexity that wasn't there before. I tried to follow the argument in the comments, especially seeing that |
The parser takes an Object value, so should the builder. Relates to elastic#11896
I share your concerns @cbuescher around supporting Object rather than String, but thought that we already support objects everywhere (parser + mappers) so this really seemed like a leftover in the java api and it makes sense to fix it. let's ask for a second opinion from @jpountz ? :) |
Value was improperly set to `true`. Relates to elastic#11896
@javanna Thanks for the review. I updated the PR accordingly. |
|
||
/** | ||
* Returns the value used in this query. | ||
* If necessary, converts internal {@link org.apache.lucene.util.BytesRef} representation back to string. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this comment is outdated
did another round, left a few comments |
@javanna I updated the PR accordingly. Thank you. |
I think this is ready (besides my last small comment above), but it needs some rebasing before it can get in |
c7fbd35
to
5b9d5cc
Compare
@javanna It's rebased |
I think we may need to rebase again after #12200 I would wait for that one. |
5b9d5cc
to
05d3fe6
Compare
@javanna It's rebased you can take a look now. |
|
||
@Override | ||
protected Query doCreateExpectedQuery(RegexpQueryBuilder queryBuilder, QueryParseContext context) throws IOException { | ||
// NO COMMIT: fix to be removed to avoid NPE on unmapped fields |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can replace with //norelease so we don't forget but at least you can get this in while we fix this problem in master.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure i'll replace that
left two minor comments, LGTM though |
e0356dd
to
93674b8
Compare
Relates to elastic#10217 Closes elastic#11896 This PR is against the query-refactoring branch.
Value was improperly set to true. Relates to elastic#11896 Closes elastic#12083
Relates to #10217
This PR is against the query-refactoring branch.