You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here, add an implementation for SQLite. The new driver passes the entire
driver test suite (including some newly added tests), and checks out
against a new end-to-end suite of client tests targeting it. I think at
this point we can consider it to be largely functional, although with
minimal real-world vetting, but at least alpha quality that we can start
putting in front of users.
The main reason this turned out to be quite an effort is that SQLite,
although nominally supporting a lot of the same syntax Postgres does,
just has a lot of unexpected limitations and quirks that all need to be
tracked down separately and a workaround added. For example:
* SQLite doesn't really have data types. Everything is either an
integer, real, text, or blob, and anything more sophisticated just has
to be shoehorned into one of these types. For example, there's no
boolean. Despite the fanfare recently, there isn't even a jsonb. Jsonb
gets pushed into a blob.
* The most annoying missing data type is a timestamp. Date/times are
stored as either Unix integers or strings, and SQLite provides a
number of obnoxious, error-prone, built-ins to work with them.
* No arrays.
* No modification operations in CTEs. (Although counting my lucky stars
that CTEs are supported at least.)
* No listen/notify.
Aside from that though, we had to get some testing infrastructure in
place, and our testing has traditionally been quite affixed to Postgres,
which would've made a lot of changes necessary. However, the schema
additions in #848 do help to make this quite a bit easier with the
driver-based `TestSchema` and `TestTx` functions, and because they raise
schema automatically, it doesn't complicate test setup instructions in
any way by adding extra steps.
A new `TestDriverRiverSQLite` test has been added to run the full
barrage of driver tests for SQLite. I've also added a new family of
`TestClientWithDriver` tests that are similar to `TestDriver*` in that
they run for each of our supported drivers, but in this case they do a
series of end-to-end tests to more fully exercise the entire River
client. I added a respectable set of base client driver tests that walks
each driver through all basic functionality (including for features that
are higher risk of failing from one database compared to the next like
`JobList`), but as with most tests, they could stand to be extended
further, which I'm sure we'll get to in the future.
An example test for SQLite has been added, demonstrating the use of
River with a SQLite driver and in-memory SQLite database.
A few caveats:
* I've found that the combination of SQLite's reduced capabilities +
sqlc's bugginess [1] make bit batch insert/update operations basically
impossible (I tried every workaround I could possibly thin of), so
these are done in loops of individual operations instead. I *think*
this is okay for now though. For one, sqlc will hopefully get these
limitations fixed eventually, and for two, SQLite databases will often
be running locally, meaning the round trip cost per operation is much
lower than what we'd see in a hosted Postgres somewhere.
* It's not totally clear that having a SQLite implementation will be
"worth it enough" in the long run given that it will add some
difficulty to non-trivial future database-related operations. My hope
is that as it's in a prerelease state, we can gauge how bad it is to
keep up to date. If it feels like way more effort than it's worth, we
can still axe it before it ever becomes a functional driver.
[1] sqlc-dev/sqlc#3802 (comment)
Copy file name to clipboardExpand all lines: CHANGELOG.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
7
7
8
8
## [Unreleased]
9
9
10
+
### Added
11
+
12
+
- Preliminary River driver for SQLite (`riverdriver/riversqlite`). This driver seems to produce good results as judged by the test suite, but so far as minimal real world vetting. Try it and let us know how it works out. [PR #870](https://github.com/riverqueue/river/pull/870).
13
+
10
14
## [0.22.0] - 2025-05-10
11
15
12
16
### Added
@@ -19,6 +23,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
19
23
20
24
### Fixed
21
25
26
+
- Resuming an already unpaused queue is now fully an no-op, and won't touch the row's `updated_at` like it (unintentionally) did before. [PR #870](https://github.com/riverqueue/river/pull/870).
22
27
- The `riverdatabasesql` now fully supports raw connections through [`lib/pq`](https://github.com/lib/pq) rather than just `database/sql` through Pgx. We don't recommend the use of `lib/pq` as it's an unmaintained project, but this change should help with compatibility for older projects. [PR #883](https://github.com/riverqueue/river/pull/883).
0 commit comments