Skip to content

Latest commit

 

History

History
79 lines (56 loc) · 1.98 KB

File metadata and controls

79 lines (56 loc) · 1.98 KB

schema_migrations

Purpose

Tracks the schema migration version applied to the database.

Grain

Exactly one row, pinned to id = 1 after migration 063. Every _set_version call replaces the row in place; the PK + CHECK make duplicate or stray-id rows impossible.

Live Stats

  • Snapshot source: data/pyvalue.db on 2026-07-28
  • Row count: 1
  • Table size: 4,096 bytes (4.0 KiB)
  • Approximate bytes per row: 4,096.0

Columns

Column Type Null Key Notes
id INTEGER no PK always 1; CHECK (id = 1) enforces the single-row invariant
version INTEGER no applied schema version

Keys And Relationships

  • Primary key: id
  • Physical foreign keys: none
  • Physical references from other tables: none
  • Unique constraints beyond the primary key: none
  • Main logical refs: none

Secondary Indexes

  • None beyond the primary key and unique constraints.

Main Read Paths

  • migration bootstrap

Main Write Paths

  • migration runner

Column Usage Notes

  • version: compared by the migration bootstrap to determine which schema upgrades still need to run.

Sample Rows

  • Snapshot source: data/pyvalue.db on 2026-07-28
  • Sample window: first 1 rows returned by SQLite ordered by version ASC
[
  {
    "id": 1,
    "version": 91
  }
]

Review Notes

  • Single-row semantics are now enforced by the schema (id INTEGER PRIMARY KEY CHECK (id = 1)). _set_version uses DELETE FROM schema_migrations; INSERT INTO schema_migrations (version) VALUES (?) — SQLite auto-picks id = 1 for the insert because the table is empty, so the CHECK passes.