migrations

No inbound migration — this is the base version.

lesion_calculation v1 has no predecessor, so there is nothing to migrate from: this module intentionally defines no upgrade/downgrade.

Why no create_table here (and no drop_table downgrade), unlike canonical Alembic where revision 1 creates the table? In this cache the ORM (schema.py) owns table existence: a missing table is created directly from its target-version ORM by ensure_types (implementations/sqlite.py), never by replaying a v1 migration. Migrations model only the incremental delta between two existing versions (vN.upgrade = v(N-1) -> vN), so v1 — having no prior version — has no delta to emit. A v1 create_table would also just restate the ORM, reintroducing the drift the "ORM is the single source of truth" rule avoids. The driver never even reaches v1: _apply_upgrades walks versions current+1 .. target with current >= 1, so get_upgrade(name, 1) is never called. Later versions (v2+) get autogenerated upgrade(op) / downgrade(op) via python -m bitfount.cache.tools.gen_migration.

---