Previously, when `TZ` was set to an invalid value, Jiff would still
attempt to detect the system configured time zone. But this is arguably
not great, because it silently (aside from logs) rejects an invalid
`TZ` value. In reality, if `TZ` is set, it is likely that the user
intends for it to have an impact. So if it doesn't, we should bleat
about it.
This manifests as an error when using `TimeZone::try_system()` and
manifests as a error sentinel in the form of `Etc/Unknown` when using
`TimeZone::system()`.
We also tweak some of the logging levels. Namely, in #370, I increased
the number of TRACE-level log messages, which makes it much noisier. So
I've promoted a few things that were TRACE to DEBUG without making the
output much noisier. I guess TRACE should be reserved for variable
length things.
Fixes#364
I'm not sure when or how exactly it happened, but in the last weeks,
I've noticed that `rustc` gets effectively stun-locked whenever I make a
change to a source file in Jiff. A quick examination of what the fuck my
computer is doing seems to reveal that it's spending oodles of time
compiling diesel over and over.
I have no idea why this is happening and I don't really care to spend
the time unraveling the mysteries of diesel.
So I took a hammer to the problem. I have effectively shunted all
examples and all "integration" crates out of Jiff's core workspace and
into their own little bloated fiefdoms. To compensate for the fact that
`cargo test --all` no longer tests these things, I've added shell
scripts to run the requisite tests. And those shell scripts are now run
in CI.
I'm now back to a state where I can save a file in Jiff and I get
sub-second `cargo check` response times.
This moves the majority of tests to use the `Insertable` and `Selectable`
derivations from the query struct. This follows idiomatic Diesel usage, and
also tests actual database round-tripping via database stores.
The downside of this is that tables need to exist; I have created temporary
tables in this PR for this purpose (which are dropped when the session
is closed).
PR #254
This is like #240, but adds a crate with wrapper types that implements
Diesel traits. Unlike with SQLx, and unless I'm missing something,
Diesel actually exposes enough of an API to implement datetime support
for MySQL. So that's included here.
Diesel does seem to use some internal privileged APIs for its own
`chrono` and `time` integration that avoids unnecessary allocations
when parsing datetimes from SQLite values. Again, unless I'm missing
something, Jiff is forced to allocate into a `String` first. (But Jiff
only really needs a `&[u8]`.)
I found this experience, along with SQLx, to be absolutely mind-numbing.
Just writing out the example code (which I also used for ad hoc testing)
took an incredible amount of time. I spent _way_ more time playing
fucking type tetris with both SQLx and Diesel than I did anything else
_combined_. It's utterly ridiculous. This further solidifies my opinion
that when you publish crates with an obscene amount of inter-connected
traits, the resulting API becomes very difficult to use.
I'm happy to iterate on the implementation and APIs of this crate (and
`jiff-sqlx`) after an initial release. But I very much appreciate
reviews from Diesel and SQLx experts.
I'm going to say that this closes#50 since this I think this, along
with `jiff-sqlx` and `jiff-icu`, gives us a solid foundation to build
upon. We can track more specific integrations in new issues.
Closes#50
This PR adds a new `jiff-sqlx` crate. It defines wrapper types for
`Timestamp`, `DateTime`, `Date`, `Time` and `Span`. For each wrapper
type, the SQLx encoding traits are implemented. (Except, with `Span`,
only the decoding trait is implemented.)
This is similar to #141, but organizes things a bit differently. This
also comes with SQLite support. MySQL support is missing since it seems,
at present, to require exposing APIs in SQLx for a correct
implementation.
This initial implementation also omits `Zoned` entirely. I've left a
comment in the source code explaining why. The quick summary is that, at
least for PostgreSQL, I don't see a way to provide support for it
without either silently losing data (the time zone) or just storing it
as an RFC 9557 timestamp in a `TEXT` field. The downside of the latter
is that it doesn't use PostgreSQL native datetime types. (Becuase we
can't. Because PostgreSQL doesn't support storing anything other than
civil time and timestamps with respect to its datetime types.) I do
personally lean toward just using RFC 9557 as a `TEXT` type, but I'd
like to collect real use cases first to make sure that's the right way
to go.
Ref #50, Closes#141
Ref https://github.com/launchbadge/sqlx/issues/3487
