02fca2ad3c
ADR 0021 records the catch-up rules and amends ADR 0003 and 0005, whose claims about secondary profiles were false. architecture.md, CLAUDE.md and the migration rule describe the two migration paths; the guide tells where the pre-update copy lives and how to remove a database a deletion on Linux left behind. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
16 lines
1.2 KiB
Markdown
16 lines
1.2 KiB
Markdown
---
|
|
paths: ["**/migrations/**", "**/*.sql", "**/lib.rs", "**/profile_db.rs"]
|
|
---
|
|
Ne JAMAIS modifier une migration SQL existante. Toujours creer une nouvelle migration.
|
|
Les checksums sont verifies au demarrage (SHA-384 dans `_sqlx_migrations`) et epingles par le test `migration_checksums_match_the_released_ones`.
|
|
Les migrations sont inline dans `lib.rs`, rendues par `migrations()` via `tauri_plugin_sql::Migration`.
|
|
Le schema consolide (`consolidated_schema.sql`) sert uniquement pour les nouveaux profils.
|
|
|
|
Depuis #390 (ADR 0021), chaque nouvelle migration atteint deux chemins :
|
|
- le profil par defaut, migre par tauri-plugin-sql (sqlx) ;
|
|
- les profils secondaires, rattrapes a l'ouverture par `database::profile_db` (rusqlite), cles etrangeres actives comme sous sqlx.
|
|
|
|
Une migration doit donc rester correcte sur les deux, et :
|
|
- tout changement de schema se reporte dans `consolidated_schema.sql` (le test des etats publies compare chaque profil rattrape a un profil neuf) ;
|
|
- toute correction de donnees (seed, mots-cles, categories) se reporte AUSSI dans `consolidated_schema.sql` : un nouveau profil nait avec l'historique complet et ne rejoue jamais les migrations ;
|
|
- ne pas ajouter de marqueur a `infer_floor` : il ne sert qu'aux bases creees avant #390.
|