-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Upgrade to time 0.3 #1455
Merged
Merged
Upgrade to time 0.3 #1455
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Wouldn't
#[serde(with = "time::serde::rfc3339")]
(as described in this comment) require theserde-well-known
feature flag? Since serializing with RFC3339 format is a very common use case, I guess addingserde-well-known
would make sense...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.
Generally you don't want to enable feature flags you don't strictly need. That would force that feature on for all crates that depend on SQLx.
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.
Makes sense... but what is then the recommended way to read a timestamp from the database and put it into a DTO in RFC3339 format? Since the version of
time
that sqlx comes with doesn't support this (due to version and that feature flag), a user of sqlx has to use an intermediate "DatabaseDTO" withsqlx::types::time::OffsetDateTime
for fetching from the database (usingquery_as
), just to then convert it manually into an "ActualDTO" withtime::OffsetDateTime
(I did that withtime::OffsetDateTime::from_unix_timestamp(db_dto.created_at.unix_timestamp())
, but I'm not sure that's the best way). Only then the aforementioned way to serialize a timestamp using RFC3339 withwith
actually works. Or am I missing something?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.
That's only an issue because SQLx is currently using a different version of
time
than you are. Otherwisesqlx::types::time::OffsetDateTime
andtime::OffsetDateTime
should always refer to the same type.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.
time::serde::rfc3339
exists sincetime
v0.3.6, so it's not available in the version proposed in this PR (which meansserde-well-known
would only make sense when using >= 0.3.6 anyway; before that, there is no such feature flag).I get that enabling too many features is not a good idea as it would impact lots of users. But what about going with a more recent version of time, i.e., >=0.3.6? That would make it easier for anyone trying to include timestamps in REST API responses :)
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.
sqlx depending on
0.3.2
means versions>=0.3.2, <0.4.0
are allowed, so you're free to use features from newer patch versions of the time crateThere 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.
The version specified here is not restrictive and Cargo will automatically pull in the latest
0.3.x
release if it's not in yourCargo.lock
already when building your crate.You should also specify
time = { version = "0.3.6", features = ["serde-well-known"] }
in your own dependencies to be certain of this.