-
Notifications
You must be signed in to change notification settings - Fork 7
Added new operator to check IP within range #185
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
Changes from all commits
582bb08
59ea812
8f89d9a
79280c6
fd2eca9
d7258e5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -146,6 +146,12 @@ private static class StringConditionArgument implements StringCondition { | |
|
|
||
| @JsonProperty(VALUE_KEY) | ||
| String value; | ||
|
|
||
| @JsonProperty(VALUES_KEY) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess it's pre-existing, but why did this class get implemented twice? Seems like a mistake here.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure. I'm guessing there's a misunderstanding on how deserialization works, but there's only one jackson mapper so no interface needs to be implemented twice |
||
| List<String> values; | ||
|
|
||
| @JsonProperty(STRING_CONDITION_VALUE_TYPE_KEY) | ||
| StringConditionValueType stringConditionValueType; | ||
| } | ||
|
|
||
| @Value | ||
|
|
||
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.
Another alternative would be to have value be typed Object and accept either a string or list of strings in it. We're not consistent, we've taken both approaches in different places. Up to you
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 no harm in this approach, will keep it this way.
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.
no harm, the difference is how the callers would use it. In the read direction: whether they have to ask for 3 fields (value, values, type), then use type to determine which field should be read; or they ask for one field (value) and inspect the runtime value and use it accordingly. write direction: whether they have to set two fields (either value or values, then assigning type correctly depending on), or just assigning value with either one (in which case GQL now has to inspect it and determine which it is.
So the explicit is more verbose, but they both accomplish same thing.