Commit Graph
1 Commits
Author SHA1 Message Date
zoltan57andCopilot App 012dc15042 V4.6 Phase 8: one-time V4.5 -> V4.6 data migration script (review 1a)
Adds tools/migrate_v45_to_v46.py, the final V4.6 deliverable.

Diffing the backup against the current SQLModel metadata showed that the
re-level changed no columns: both have the same 10 tables with identical
column sets. What changed is index coverage [HIGH-04], the use_alter break in
the source/execution_attempt foreign key cycle, and the relationship loading
strategy [CRIT-02]. The migration is therefore a faithful, foreign-key-ordered
row copy rather than a transformation.

Design:

- The backup is read with plain sqlite3 rather than through the ORM. The plan
  anticipated ORM reads carrying explicit eager loads under lazy="raise";
  raw reads are strictly safer, because the V4.5 file is not guaranteed to
  satisfy the V4.6 mappers and no relationship is ever traversed.
- Writes go through SQLAlchemy Core against the live metadata, so the script
  works unchanged against PostgreSQL when that cutover happens.
- source rows are inserted with preferred_execution_attempt_id cleared and the
  selections are replayed after execution_attempt is populated, matching the
  use_alter break in the cycle.
- _coerce() converts raw SQLite values into what each column binds. It accepts
  both enum spellings, because job_source.status declares values_callable and
  stores lowercase values while execution_attempt.status does not and stores
  uppercase names, despite both using JobSourceStatus.
- Idempotent: a row whose primary key already exists is skipped, never
  updated. Never invoked from application startup and never run by the test
  suite.
- A pre-flight guard aborts if the backup row counts do not match the recorded
  V4.5 snapshot, so the script cannot silently run against the wrong file.

Verification against a throwaway target:

- 282 rows copied; per-table counts match the plan exactly (document 8,
  document_person 11, document_type 7, execution_attempt 80, job 11,
  job_source 79, person 5, person_role 3, processing_artifact 2, source 76).
- Every table is cell-for-cell identical to the backup across all columns.
- A second run inserts 0 rows and skips all 282.
- Artifact integrity passes for every migrated artifact, checked through the
  application's own SourceService verifier.
- 9 indexes added, 0 lost. No on-disk Source, portrait, or artifact file is
  written by the script.

The live data/transcription.db is deliberately left untouched; it currently
holds only bootstrap seed rows whose UUIDs differ from the backup.

Co-authored-by: Copilot App <[email protected]>
2026-08-17 20:02:34 -05:00