demo · v149
Transaction Durability
The motivation for the SQLite backend is reliability — bug reports of missing or partially-written records. This demo runs three classic correctness scenarios that exercise atomicity, isolation, and the strict durability mode. Pass means the implementation behaved as IndexedDB promises.
1 · atomic abort
Write 100 records, then throw mid-loop. Re-open and count — should be 0. A torn write would surface as a partial count.
2 · isolation
Open two overlapping readwrite transactions on the same store. The second should queue behind the first, never interleave. Verify by writing a sentinel value from each.
3 · strict durability
Open with { durability: "strict" } and write a record. Read the same key back from a fresh connection. Should always return the latest value.
console
why these tests
The SQLite migration is invisible to the API surface — these are the same IDB operations a real app issues every day. The difference shows up only when something goes wrong: a forced abort, an overlap, a write that needed to actually fsync. The pre-149 LevelDB hybrid had bug reports for each of these classes. On SQLite, the engine handles them natively.
see also
- IndexedDB SQLite backend — feature index
- Bulk Write Stress Test — throughput benchmark
- ChromeStatus entry — step 2
- IndexedDB spec
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗