hesela.devSQLite serialization
SQLite serialization exports a selected database on one connection as a contiguous database-file image.
The API selects a connection and a named database. This is a binary database image, not an SQL text dump or the transaction-isolation property called serializability. The ordinary call allocates a copy; NOCOPY can return NULL when no contiguous representation exists. [1]
In Hesela's controlled SQLite 3.45.1 and 3.54.1 runs, a writer exported changed rows before rolling back. The detached image retained values never committed in the source database and passed integrity_check. A separate private-cache reader and a backup reaching SQLITE_DONE through that reader retained the committed base rows. These are native fixture observations, not failure-rate estimates. [4] [3]
Successful sqlite3_deserialize setup is a separate check from successful queries. In each capture, all nine WAL-header images returned SQLITE_OK from setup but SQLITE_CANTOPEN on use. Setting input-buffer bytes 18 and 19 to 0x01 before deserialization enabled reads, as documented. This detached-buffer conversion does not establish commit provenance or reconstruct omitted WAL content; never treat it as live-database repair. [2] [4]
A pinned WAL reader can export an older committed view after another connection commits. Validate the intended source state, actual recovery-path queries and application expectations separately. Structural consistency and byte identity do not establish freshness. [3] [5]
Relations
- related
- SQLite Online Backup API, SQLite transaction state, SQLite WAL end mark, Physical database backup, Logical database backup, Serializability, Backup verification, Restore test
Limitations
- The two tested builds have different compile configurations; their comparison does not isolate a version effect.
- Shared-cache read_uncommitted behavior and arbitrary malformed input were not tested.
Citations
- SQLite C API: Serialize a database, connection/schema scope and copy flags
- SQLite C API: Deserialize a database, WAL-mode input restriction
- SQLite: isolation between connections and retained WAL snapshots
- Hesela: frozen two-build serialization observations and source identities
- Hesela: serialized images, source commit provenance and recovery acceptance
Sources & caveats
- Controlled native C API calls with private caches, explicit transaction ordering and disabled writer cache spilling; 16 image origins per build, two original captures each, three restore paths. No process-crash, power-loss or production-incidence inference.