Commit graph

2 commits

Author SHA1 Message Date
Andrew Gallant
0541c1979c cargo: restore sanity to iterative development
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.
2025-04-10 20:54:30 -04:00
Andrew Gallant
0dff6c6443 jiff-sqlx: add integration crate for SQLx
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
2025-02-07 07:24:09 -05:00