Sqlite session store

[oliverbarnes]

Closes #465

Tries to follow the implementation for Postgres as close as possible.

TODO

• test manually on generated app (repo) adapting examples from the sessions installation guide
• programmatic tests
• update sessions installation guide (WIP - have yet to generate the tute to view it)

Key Differences from PostgreSQL Implementation

Aspect	PostgreSQL	SQLite	Reason
JSON Storage	JSONB	JSONB	✅ Both now use binary JSON
ID Type	UUID	TEXT	SQLite lacks native UUID support
Timestamps	TIMESTAMPTZ + jiff-sqlx	INTEGER (Unix)	Different time handling approaches
Time Functions	(now() AT TIME ZONE 'UTC')	unixepoch()	Database-specific SQL functions
Parameter Binding	$1, $2, $3	?, ?, ?	Different SQL parameter syntax
Index Creation	Complex PL/pgSQL block	Simple IF NOT EXISTS	Different SQL capabilities
Batch Deletion	DELETE ... LIMIT	DELETE ... WHERE id IN (SELECT ... LIMIT)	SQLite doesn't support LIMIT in DELETE
Error Codes	"23505"	"1555"	Different constraint violation codes

Usage

let pool = sqlx::SqlitePool::connect("sqlite://sessions.db").await?;
let backend = SqliteSessionStore::new(pool);
backend.migrate().await?; // Run migrations

Files Added

• libs/pavex_session_sqlx/src/sqlite.rs - Complete SQLite session store implementation
• Updated libs/pavex_session_sqlx/src/lib.rs - Export SQLite types
• Updated libs/pavex_session_sqlx/Cargo.toml - Add SQLite feature

[LukeMathWalker]

It looks like we are going in the right direction!
A few things:

• No need to include a kit, nor documentation examples. Kits are going away in the next release, and the doc examples will substantially change, so we can spare that work here.
• Let's add unit tests. In particular, we should cover:
  • Migration idempotency
  • TTL expiry
  • Roundtrip tests ensuring that we can read back what we wrote, including updates too.

[oliverbarnes]

Done. I've used sqlite's memory store for the tests, for speed and to avoid permissions issues. Let me know if you'd prefer me to stick to using a file instead

[LukeMathWalker]

The happy path is well-covered by tests now. We should focus on testing the unhappy path:

• Duplicate ids errors should be tested
• Unknown ids errors should be tested
• If we can find a way to test unexpected errors, even better, but it's not as important at this point

You can invoke cargo llvm-cov --html --open --features sqlite from the pavex_session_sqlx folder to see what is or isn't covered by tests at the moment. It requires cargo-llvm-cov.

[oliverbarnes]

Good point, and I didn't know about llvm-cov thanks - coverage now at high 80s (from high 60s).

Gonna do the same with the mysql implementation, now.

[LukeMathWalker]

/ok-to-test sha=c6bf07b