30 lines
1.2 KiB
Markdown
30 lines
1.2 KiB
Markdown
# ADR 0010: cr-sqlite DB Sync
|
|
|
|
## Status
|
|
|
|
Accepted.
|
|
|
|
## Decision
|
|
|
|
Database sync uses local SQLite databases with cr-sqlite-compatible
|
|
`crsql_changes` tables or views. Geth extracts typed change batches, exchanges
|
|
them over the protected Iroh control path, checks schema metadata before
|
|
application, and applies compatible batches through the local `crsql_changes`
|
|
interface.
|
|
|
|
The prototype does not add a second snapshot transport for DBs. CAS-backed DB
|
|
snapshots or change-batch blobs are deferred until the change path proves too
|
|
large for the control path or until initial peer catch-up needs snapshots.
|
|
|
|
## Consequences
|
|
|
|
The prototype has deterministic fixture coverage for extraction, application,
|
|
two-node Iroh exchange, authorization, schema mismatch detection, and live-sync
|
|
watermarks.
|
|
|
|
A real cr-sqlite extension integration test is intentionally not marked done in
|
|
this environment because there is no `sqlite3` CLI or cr-sqlite extension
|
|
artifact available to load. The blocker is environmental, not a protocol
|
|
decision. When the extension is available, add a two-node test that creates a
|
|
real cr-sqlite-enabled table, mutates one node, runs `geth db sync`, and proves
|
|
the second node applies the change through cr-sqlite.
|