Building of this binary is controlled with features, allowing downstream
users to build just the SQLite version and not be concerned with the
tokio-postgres dependency tree (which includes links to OpenSSL and
other details). The Postgres version is disabled by default.
This does not change the binary name for the SQLite build, just to avoid
confusion for people upgrading to the new version.
* fix clap error
Signed-off-by: Cameron Wong <cam@camdar.io>
* Refactor to test more arg-parsing
---------
Signed-off-by: Cameron Wong <cam@camdar.io>
Co-authored-by: Cameron Wong <cam@camdar.io>
* Document RELEASING.md process
* Bump version numbers
* Do not automatically produce GH releases, and do not build binaries to attach to them
* Only build docker images on tags
* Use the `latest` Docker image tag in the Docker-compose config
Transactions for different client_ids cannot interfere with one another,
so this provides an opportunity for the sort of concurrency that a
mult-client hosting solution might need. For example, a postgres backend
could lock the client row in each transaction.
This is a bit tricky because the `Storage` trait is `Send + Sync`, but
an SQLite connection is neither. Since this is not intended for
large-scale use, the simple solution is just to open a new SQLite
connection for each transaction. More complex alternatives include
thread-local connection pools or a "worker thread" that owns the
connection and communicates with other threads via channels.
This also updates the InMemoryStorage implementation to be a bit more
strict about transactional integrity, which led to a number of test
changes.
This will cause these to be displayed even without $RUST_LOG set. If
RUST_LOG=debug, the message is printed twice (once at the debug level by
the built-in `Logger` middleware), but this is better than not at all.
