Skip to content

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

Closed
wants to merge 2 commits into from
Closed

Support for DateTime queries #362

wants to merge 2 commits into from

Conversation

vaind
Copy link
Contributor

@vaind vaind commented Dec 31, 2021

closes #287

  • cherry-pick add datetime queries in docs #327 - currently the proposed docs wouldn't work
  • decide how-when to make the switch - either a breaking change with v2.0, or make it configurable?

Copy link
Member

@greenrobot-team greenrobot-team left a 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.

Comment on lines +896 to +903
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])),
Copy link
Member

@greenrobot-team greenrobot-team Jan 10, 2022

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?

Copy link
Contributor Author

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

Copy link
Member

@greenrobot-team greenrobot-team Jan 17, 2022

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.

@greenrobot-team
Copy link
Member

Superseded by internal merge request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support DateTime query conditions (or at least document current approach)
2 participants