b0206ae56b
tauri-plugin-sql migrates only the database registered with add_migrations, the default profile's. A secondary profile kept the consolidated schema of the version that created it and never received a migration afterwards. prepare_profile_db runs before every Database.load: - secondary profiles catch up with the same migrations() list (pinned SHA-384), history kept in _sqlx_migrations; a database without history gets a floor inferred from its schema (the seven released creation states are test fixtures), so nothing at or below it is ever replayed; - a VACUUM INTO copy is taken before the first write, synced, then renamed; - each version runs in its own transaction with foreign keys on; one that fails on a foreign key is retried once without them and its orphans are set to NULL where the key declares ON DELETE SET NULL; - every profile gets its TEXT manual-categorization flags repaired; - failures are logged with file names only and the profile still opens. New profiles are born with their full history (get_new_profile_init_sql). The plugin keeps databases under app_config_dir(), not app_data_dir(): the same folder on Windows and macOS, not on Linux. repair_migrations, delete_profile_db and compute_account_return looked in the wrong folder there. profile_db_path resolves the plugin's folder and validates the file name; deleting a profile now also removes its SQLite side files and catch-up copies. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| capabilities | ||
| icons | ||
| src | ||
| .gitignore | ||
| build.rs | ||
| Cargo.lock | ||
| Cargo.toml | ||
| tauri.conf.json | ||