feat(refid): add raw-SQL sqlite backend

[sthanikan2000]

Summary

• Adds github.com/OpenNSW/core/refid/sqlite, mirroring refid/postgres's shape (DefaultTableName, Option, WithTableName, New, Migrate, Next) via database/sql + the pure-Go modernc.org/sqlite driver — no CGO. Next is the same single atomic upsert-and-increment statement as postgres, just SQLite dialect.
• New pins the passed *sql.DB to a single connection (db.SetMaxOpenConns(1)): SQLite allows only one writer at a time, and without this, concurrent Next calls can each open their own connection and race into a SQLITE_BUSY ("database is locked") error instead of one simply queueing behind the other. Since Next is one fast statement with no transaction held across calls, this costs negligible throughput.
• Documents the SQLite backend and the bring-your-own-Store escape hatch in the README.

Why

A pure-Go SQLite option avoids imposing a CGO build requirement on every downstream service for an optional backend, and gives local development and tests a real, on-disk backend with no external service dependency — tests run unconditionally in-process, unlike the Postgres backend's POSTGRES_TEST_DSN-gated integration test.

This PR is purely additive on top of #176 (stacked on that branch, per its updated description) — refid/postgres keeps working unchanged throughout. Base is refactor/refid-store-interface, not main; retarget once #176 merges.

Test plan

• go build ./..., go vet ./..., golangci-lint run ./... all clean in refid/
• go test -race ./... passes in refid/, including a 50-goroutine concurrent-Next-no-duplicates test (initially caught the SQLITE_BUSY issue SetMaxOpenConns(1) fixes, before the fix was added)

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: ed03dc14-5383-4e2d-b5e0-0f00143ab492

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ginaxu1]

PTAL these issues:

1. New mutates the caller's pool (refid/sqlite/store.go)
   db.SetMaxOpenConns(1) applies to every user of that *sql.DB, not just Next. A caller that shares the handle (normal SQLite usage: one file, one pool) has all queries serialized. Worse, a held *sql.Tx occupies the only connection, so Generate/Next waits forever. The package comment says this backend "makes no requirements on the caller's *sql.DB connection-pool configuration"; the constructor does the opposite.

Suggested fix: do not change pool settings. Guard Next with a mutex so in-process concurrent Generate cannot hit SQLITE_BUSY. For lock waits on the file (other connections or processes), set busy_timeout on every connection, e.g. document opening with _pragma=busy_timeout(5000) in the DSN (a one-shot PRAGMA busy_timeout on db.Exec only affects that one pooled connection). Keep the 50-goroutine test; it should still pass with the mutex and no SetMaxOpenConns. Add a test that Begin()s a Tx on the same *sql.DB, then calls Next with a short context deadline: it must not hang.

2. Multi-process Store contract is unmet
   refid.Store requires concurrent safety "across multiple process instances sharing the same backing store". A second process (or a second sql.Open on the same file) still gets SQLITE_BUSY because busy_timeout is never set. SetMaxOpenConns(1) only serializes one *sql.DB.

Suggested fix: same DSN/pragma as (1). If this backend is single-process (dev/tests only), say that on the package and do not claim it satisfies the multi-process clause. Production multi-instance deployments stay on postgres.

[sthanikan2000]

@ginaxu1 Good catch, both fixed in f84ee67.

1. Removed db.SetMaxOpenConns(1) — New no longer touches the pool. Next is now guarded by an in-process mutex instead, so concurrent calls queue instead of racing into SQLITE_BUSY. Added the Begin()-a-Tx-then-Next test you suggested; confirmed it actually catches the old bug before restoring the fix.
2. Agreed we can't fully close this for SQLite — docs now say plainly this backend covers single-process use only, recommend _busy_timeout in the DSN for cross-connection/process waiting, and point multi-instance deployments at refid/postgres instead.

Checked #176 too — neither point applies there. Postgres's New never touches the pool, and its single atomic statement is already safe across processes by construction (real row-level locking, not a whole-file lock).

[ginaxu1]

Lgtm

[sthanikan2000]

#181 Duplicate