9ed79b4fa3
schema.sql was modified in v0.2.5 to include is_inputable column and import_config_templates table. Since schema.sql is include_str!'d into migration 1, this changed its SHA-256 checksum in sqlx's migration tracker, blocking migrations 4 and 5 from running. Reverts schema.sql to its original v0.2.4 state so the checksum matches and new migrations can apply. Fixes both "no such table: import_config_templates" and is_inputable defaulting to false. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1.4 KiB
1.4 KiB
Task: Fix import_config_templates "no such table" + category is_inputable default
Root Cause Analysis
Both bugs share the same root cause: schema.sql was modified in v0.2.5 to include
is_inputable column and import_config_templates table. Since schema.sql is compiled
into migration 1 via include_str!("schema.sql"), this changed migration 1's SQL content.
The tauri-plugin-sql uses sqlx::migrate::Migrator which stores SHA-256 checksums
of each migration's SQL. When the checksum for migration 1 changed, sqlx refused to apply
any new migrations (4 and 5), causing both bugs:
- Bug 1: Migration 5 never ran →
import_config_templatestable doesn't exist - Bug 2: Migration 4 never ran →
is_inputablecolumn doesn't exist →SELECT *returnsundefinedfor that field → checkbox appears unchecked (falsy)
Plan
- Revert schema.sql to v0.2.4 state (remove is_inputable from categories, remove import_config_templates table)
- Add comments in schema.sql noting later migrations add these
- Verify Rust compiles cleanly
- Confirmed: sqlx Migrator uses SHA-256 checksums → changing schema.sql broke migration chain
Review
Single file changed: src-tauri/src/database/schema.sql. Reverted to match original migration 1
content. After rebuild, the checksum will match and migrations 4+5 will apply automatically.
User just needs to rebuild and restart — no database deletion needed.