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

feat: Support for range queries on time fields #429

Merged
merged 3 commits into from Aug 18, 2022
Merged

feat: Support for range queries on time fields #429

merged 3 commits into from Aug 18, 2022

Conversation

adilansari
Copy link
Contributor

No description provided.

@codecov-commenter
Copy link

codecov-commenter commented Aug 18, 2022

Codecov Report

Merging #429 (11ff070) into main (bcbe062) will increase coverage by 0.09%.
The diff coverage is 36.36%.

@@            Coverage Diff             @@
##             main     #429      +/-   ##
==========================================
+ Coverage   29.75%   29.84%   +0.09%     
==========================================
  Files          77       78       +1     
  Lines        8173     8222      +49     
==========================================
+ Hits         2432     2454      +22     
- Misses       5495     5522      +27     
  Partials      246      246              
Impacted Files Coverage Δ
query/filter/selector.go 27.08% <0.00%> (-3.15%) ⬇️
schema/schema.go 67.40% <ø> (ø)
server/services/v1/search_indexer.go 13.19% <0.00%> (-1.84%) ⬇️
schema/fields.go 81.15% <75.00%> (+1.15%) ⬆️
lib/date/converter.go 100.00% <100.00%> (ø)
schema/collection.go 67.15% <100.00%> (+2.58%) ⬆️
schema/reserved.go 100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@adilansari adilansari marked this pull request as ready for review August 18, 2022 16:45
@adilansari adilansari changed the title refactor: Index datetime fields as int64 feat: Support for range queries on time fields Aug 18, 2022

// ToUnixNano converts a RFC3339
func ToUnixNano(dateStr string) (int64, error) {
t, err := time.Parse(RFC3339Nano, dateStr)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

What's a good way to detect date format from user input? I would prefer to add additional layouts here.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe use a library? https://github.com/araddon/dateparse
Not ideal though. New dependency.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I guess better to stick to standard date time, else it can cause confusions and different queries can return different results.

Copy link
Collaborator

Choose a reason for hiding this comment

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

So the date time format is defined by us, which we are using for validation purposes. Let's stick to that format.

Also, this format needs to be in the schema package close to the DateTime data type so that we know that this format is what we are proposing to the end user for this data type. This function can still stay here and you can accept the format which will be defined in the schema package.

lib/date/converter.go Outdated Show resolved Hide resolved
schema/reserved.go Outdated Show resolved Hide resolved
@adilansari adilansari merged commit d19ac5e into main Aug 18, 2022
@adilansari adilansari deleted the range branch August 18, 2022 23:30
@tigrisdata-argocd-bot
Copy link
Collaborator

🎉 This PR is included in version 1.0.0-alpha.31 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

@tigrisdata-argocd-bot
Copy link
Collaborator

🎉 This PR is included in version 1.0.0-beta.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

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.

None yet

5 participants