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

Refactoring of RegexpQuery #11896

Conversation

alexksikes
Copy link
Contributor

Relates to #10217

This PR is against the query-refactoring branch.

@javanna
Copy link
Member

javanna commented Jul 1, 2015

heya @alexksikes sorry may I ask you to rebase please? #11974 changed things quite a bit, for the better!

@alexksikes alexksikes force-pushed the feature/query-refactoring-regexp branch from aa9bdfa to ba70a71 Compare July 2, 2015 00:40
@alexksikes
Copy link
Contributor Author

@javanna OK you can go ahead, it's rebased. Thank you.

flags.add(flag);
}
}
query.flags(randomFrom(flags));
Copy link
Member

Choose a reason for hiding this comment

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

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 what I wanted to do is generate arrays of unique flags. I'll fix this.

@javanna
Copy link
Member

javanna commented Jul 2, 2015

I did a first round of review, left a few comments


@Test
public void testValidate() {
RegexpQueryBuilder commonTermsQueryBuilder = new RegexpQueryBuilder("", "regex");
Copy link
Member

Choose a reason for hiding this comment

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

rename variable to regexpQueryBuilder?

@javanna
Copy link
Member

javanna commented Jul 6, 2015

left a few comments

@alexksikes
Copy link
Contributor Author

@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",
Copy link
Member

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?

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 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.

@javanna
Copy link
Member

javanna commented Jul 7, 2015

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;
Copy link
Member

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.

Copy link
Member

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

Copy link
Contributor Author

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?

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 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

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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?

Copy link
Contributor Author

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

@cbuescher
Copy link
Member

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 value was Object and also parsed as that in the current parser code. However I feel that using numbers/date values as regex is a little bit strange, would be interested in the reason why this is allowed in the parser (it apparently was introduced long ago with Commit 22077d1).
Looking at how value = parser.objectBytes(); currenty cannot return Date object, I think this doesn't have to be supported since any value will be converted using toString() later anyway.

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

Relates to elastic#11896
@javanna
Copy link
Member

javanna commented Jul 7, 2015

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 ? :)

alexksikes added a commit to alexksikes/elasticsearch that referenced this pull request Jul 7, 2015
Value was improperly set to `true`.

Relates to elastic#11896
alexksikes added a commit that referenced this pull request Jul 7, 2015
Value was improperly set to true.

Relates to #11896
Closes #12083
alexksikes added a commit that referenced this pull request Jul 7, 2015
@alexksikes
Copy link
Contributor Author

@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.
Copy link
Member

Choose a reason for hiding this comment

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

this comment is outdated

@javanna
Copy link
Member

javanna commented Jul 13, 2015

did another round, left a few comments

@alexksikes
Copy link
Contributor Author

@javanna I updated the PR accordingly. Thank you.

@javanna
Copy link
Member

javanna commented Jul 13, 2015

I think this is ready (besides my last small comment above), but it needs some rebasing before it can get in

@alexksikes alexksikes force-pushed the feature/query-refactoring-regexp branch from c7fbd35 to 5b9d5cc Compare July 13, 2015 09:17
@alexksikes
Copy link
Contributor Author

@javanna It's rebased

@javanna
Copy link
Member

javanna commented Jul 13, 2015

I think we may need to rebase again after #12200 I would wait for that one.

alexksikes added a commit to alexksikes/elasticsearch that referenced this pull request Jul 13, 2015
alexksikes added a commit that referenced this pull request Jul 16, 2015
@alexksikes alexksikes force-pushed the feature/query-refactoring-regexp branch from 5b9d5cc to 05d3fe6 Compare July 23, 2015 15:08
@alexksikes
Copy link
Contributor Author

@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
Copy link
Member

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.

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 replace that

@javanna
Copy link
Member

javanna commented Jul 23, 2015

left two minor comments, LGTM though

alexksikes added a commit that referenced this pull request Jul 23, 2015
Relates to #10217
Closes #11896

This PR is against the query-refactoring branch.
@alexksikes alexksikes closed this Jul 23, 2015
@alexksikes alexksikes force-pushed the feature/query-refactoring-regexp branch from e0356dd to 93674b8 Compare July 23, 2015 15:48
@alexksikes alexksikes deleted the feature/query-refactoring-regexp branch July 23, 2015 15:48
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
Relates to elastic#10217
Closes elastic#11896

This PR is against the query-refactoring branch.
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
Value was improperly set to true.

Relates to elastic#11896
Closes elastic#12083
@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.

None yet

4 participants