hesela.devSQLite data_version
SQLite data_version is a connection-local indicator of changes committed by other connections to a particular database.
Compare successive tokens on the same physical connection, database and uninterrupted attachment lifetime, not across pooled handles or reconnects. Own commits leave this PRAGMA unchanged. [1]
A retained WAL snapshot can keep returning old rows after another connection commits. A cache must not acknowledge a new monitor token using those older rows. Ending the read transaction permits a fresh snapshot. [2] In controlled reconnect schedules, replacement handles reused the old number despite returning changed rows. An aux-only write changed aux.data_version but not main.data_version. [6]
DETACH followed by ATTACH starts another auxiliary-database lifetime. In controlled schedules, the same connection and pathname returned equal tokens despite changed rows after reattachment. Reset the baseline on successful reattachment; a schema alias is not an identity for all time. [9] [10]
changes() counts the most recent completed INSERT, UPDATE or DELETE on the caller, excluding auxiliary trigger changes; total_changes() accumulates completed row changes on that connection, including trigger work. Neither is a global committed-row ledger. [3] [4] In controlled rollback cases, these counters stayed increased after the corresponding rows were restored. [5]
SQLITE_FCNTL_DATA_VERSION is a different interface that also detects same-connection modifications. These fixtures did not call that file-control API. [8]
Relations
- related
- SQLite WAL end mark, SQLITE_BUSY_SNAPSHOT, SQLite immutable connection, Write-ahead log, SQLite integrity_check
Citations
- SQLite: PRAGMA schema.data_version
- SQLite: Isolation and WAL snapshot lifetime
- SQLite: Count The Number Of Rows Modified
- SQLite: Total Number Of Rows Modified
- Hesela: controlled change-observer and rollback observations
- Hesela: controlled connection, schema and process observations
- SQLite: SQLITE_FCNTL_DATA_VERSION
- SQLite: DETACH and auxiliary database lifetime
- Hesela: same-connection attachment lifetime controls
Further reading
Sources & caveats
- Controlled results use SQLite 3.45.1 with recorded source ID; exact token values are not portable constants.
- Reconnection models physical-handle replacement, not a specific connection pool. No power-loss or concurrent-SQL stress test was performed.
- Attachment fixtures preserve one physical observer and test both same-file reattachment and a different database under the same alias; no connection pool or concurrent SQL was exercised.