-
Notifications
You must be signed in to change notification settings - Fork 135
Support for DateTime queries #362
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
Conversation
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.
LGTM, but suggested alternative approach that should not require breaking existing code.
box.query(TestEntity_.tDate.between( | ||
dates[2].millisecondsSinceEpoch, dates[4].millisecondsSinceEpoch)), | ||
box.query(TestEntity_.tDateNano.between( | ||
dates[2].microsecondsSinceEpoch * 1000, | ||
dates[4].microsecondsSinceEpoch * 1000)), | ||
// with the new [QueryDateProperty] | ||
// box.query(TestEntity_.tDate.between(dates[2], dates[4])), | ||
// box.query(TestEntity_.tDateNano.between(dates[2], dates[4])), |
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.
Would it be possible to instead let QueryDateProperty
expand on QueryIntegerProperty
with additional methods that accept DateTime
? Then it would be possible to use either int
or DateTime
?
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.
those can't be overrides (same name, different param type), thus would need to have a different name, which isn't very good because it would be only specific to this property type (maybe confusing even with its own docs).
Other alternative I've considered is changing the argument to dynamic
on QueryDateProperty
methods. that way we can make it work with both DateTime and int, though it would be a runtime check whether a proper type was provided...
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 option (from stand-up): do it the other way round. Still change to DateTime
type (breaking change), but add methods that accept int
(e.g. betweenMs
). Then existing usages can be updated using search + replace and it would still be possible to supply milliseconds directly.
Superseded by internal merge request. |
closes #287