YantrikDB

Closes #10 — Migration v14→v15 fails: ALTER TABLE on edges view.

The bug

Same root cause as v0.7.3: DBs whose meta.schema_version got rewound while disk schema stayed advanced replay migrations against schema state that's already past them. v0.7.3 swallowed duplicate column name and already exists. v0.7.8 extends the swallow list to cover the cascading errors that surface when meta is rewound to v14 and disk is at v25 (the case Pranab's MCP database hit on the v0.7.7 → first-restart path).

What's new in run_migration_idempotent

1. Comment stripping before split-on-semicolon. The naive split was breaking on multi-line comments containing semicolons (e.g. "we add plain-typed columns and ALTER; rely on validation"). Per-line truncate at first -- is safe because migration SQL is authored in this crate.
2. execute_batch instead of execute per statement. V17_V18 has INSERT INTO ... SELECT which rusqlite's execute() rejects with ApiMisuse; execute_batch() handles the full SQL grammar uniformly.
3. Four new error patterns swallowed as already-applied / superseded:
   • Cannot add a column to a view — V14_V15 ALTER hits the edges view created by V16_V17.
   • there is already another table or index with this name — V16_V17 RENAME TO claims when claims exists.
   • no such column — RENAME COLUMN where source has already been renamed.
   • no such table — DROP/ALTER on already-renamed-away table.

False-positive risk

The no such column / no such table swallows have bounded false-positive risk: we only swallow per-statement, not per-batch. If a later statement legitimately depends on the missing artifact, that later statement still fails. The trade is "heal rewound-meta DBs silently" vs "block real bugs of this shape" — for the v0.7.x stopgap the heal direction wins because real bugs of this shape would surface in the broader test suite (1422 tests pass).

Long-term proper fix (issue #10 suggestion)

Refactor the migration runner to introspect schema state via PRAGMA table_info before each ALTER and only run statements whose target column doesn't already exist. Larger change; tracked separately. The error-swallow list is the v0.7.x stopgap.

Regression test

migration_replay_does_not_trip_on_alter_table_against_view reproduces issue #10 directly: creates a DB at current schema (edges-as-view via V16_V17), rewinds meta to 14, re-opens. Pre-fix returns Err on second open with Cannot add a column to a view; post-fix succeeds because the runner now swallows that error class plus all the cascading errors the rest of the chain produces. Sanity-checks edges is actually a view in the precondition + a record() write succeeds post-heal.

Tests

1422 library tests pass (1421 prior + 1 new). NO production-path code changed; only the runner that handles already-applied migrations.

Upgrade path

Existing deployments hit by issue #10 (any user with a database created on engine v0.6.x and running an MCP that just upgraded to v0.7.x) can now pip install --upgrade yantrikdb to v0.7.8 and the migration heals automatically on next open. No data loss, no SQL surgery, no manual fixture restoration.

🤖 Generated with Claude Code