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

Add support for int values in SearchQuery #4733

Merged
merged 3 commits into from
Apr 19, 2018
Merged

Conversation

edmundoa
Copy link
Contributor

This PR adds support for querying int values in SearchQuery, and adapts the default search operator, so that users can still find int and Date values even if they don't specify an operator.

With the changes, these are the default operators:

  • foo -> Behaves like before the changes
  • string_field:foo -> Behaves like before the changes
  • int_field:0 -> Uses an equals operator to find 0 in int_field
  • date_field:2018-04-18T12:15:00Z -> Uses an equals operator to find 2018-04-18T12:15:00Z in date_field

Edmundo Alvarez added 2 commits April 18, 2018 12:05
Add new SearchQueryField.Type for int and adapt code to support them.
Using `SearchQueryOperators.REGEX` as default is fine for String types,
but it forces users to type an operator on Date and Int types.

This commit leaves `REGEX` as default for Strings, but uses `EQUALS` for
Dates and Ints, so users can still find values if they only write the
value.
@edmundoa edmundoa added this to the 3.0.0 milestone Apr 18, 2018
@edmundoa edmundoa requested a review from bernd April 18, 2018 10:16
@bernd bernd self-assigned this Apr 18, 2018
case DATE:
return new FieldValue(parseDate(pair.getLeft()), pair.getRight(), negate);
case STRING:
return new FieldValue(pair.getLeft(), pair.getRight(), negate);
case INT:
return new FieldValue(Integer.parseInt(pair.getLeft()), pair.getRight(), negate);
Copy link
Member

Choose a reason for hiding this comment

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

Can we also use a long instead of an int here? This would make it work with very large values as well.

If MongoDB works with both, we could just parse the value into a long and rename the data type to NUMBER to make it more generic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So far I only needed an int and I tried to only implement that. I can look into it, though.

Anyway, I think NUMBER is not really good even with long support, because then I would also expect the method to work with double, float, and maybe other number types in Java. Also makes parsing the number a bit more of a challenge 😄

Copy link
Contributor Author

@edmundoa edmundoa Apr 19, 2018

Choose a reason for hiding this comment

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

That didn't work when parsing a number as long and then trying to serialize it to a DTO that has an int field. Mongojack tries to serialize the long value as an int and it fails with:
java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer

@edmundoa
Copy link
Contributor Author

edmundoa commented Apr 19, 2018

As we discussed offline, I added a LONG type additionally, so we can choose the right one to match the model object.

Copy link
Member

@bernd bernd left a comment

Choose a reason for hiding this comment

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

LGTM 👍

@bernd bernd merged commit d3f2916 into master Apr 19, 2018
@bernd bernd deleted the searchqueryfield-int branch April 19, 2018 12:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants