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>
46 lines
2.9 KiB
Markdown
46 lines
2.9 KiB
Markdown
# ADR-0003 : Migrations sqlx inline et contrainte de checksum
|
|
|
|
- **Date** : 2025-02
|
|
- **Statut** : Accepté
|
|
|
|
## Contexte
|
|
|
|
L'application utilise SQLite via `tauri-plugin-sql` pour le stockage local. Le schéma de la base de données évolue à chaque version (ajout de colonnes, nouvelles tables, changement de contraintes). Il faut un système de migration fiable qui :
|
|
- Applique les migrations dans l'ordre au démarrage
|
|
- Détecte les modifications non autorisées du schéma
|
|
- Supporte la création de nouvelles bases (nouveaux profils)
|
|
|
|
Le plugin `tauri-plugin-sql` fournit un système de migrations intégré basé sur `sqlx::migrate`, avec vérification de checksum.
|
|
|
|
## Décision
|
|
|
|
Nous utilisons les **migrations inline** définies dans `lib.rs` via `tauri_plugin_sql::Migration`. Chaque migration est une chaîne SQL embarquée dans le binaire.
|
|
|
|
En complément, un fichier `consolidated_schema.sql` contient le schéma complet (toutes les migrations fusionnées) et est utilisé pour initialiser les nouveaux profils sans rejouer les 6 migrations.
|
|
|
|
Les 6 migrations actuelles :
|
|
1. Schéma initial (13 tables, 9 index)
|
|
2. Seed des catégories et mots-clés par défaut
|
|
3. Ajout `has_header` sur `import_sources`
|
|
4. Ajout `is_inputable` sur `categories`
|
|
5. Création de `import_config_templates`
|
|
6. Changement de contrainte unique sur `imported_files`
|
|
|
|
## Conséquences
|
|
|
|
### Positives
|
|
|
|
- **Vérification de checksum** : sqlx détecte toute modification d'une migration déjà appliquée, empêchant les corruptions silencieuses
|
|
- **Migrations embarquées** dans le binaire : pas de fichiers SQL à distribuer séparément
|
|
- **Schéma consolidé** : les nouveaux profils démarrent avec un schéma propre sans passer par l'historique des migrations
|
|
- **Traçabilité** : chaque changement de schéma est versionné et documenté
|
|
|
|
### Négatives
|
|
|
|
- **Immutabilité** : une migration appliquée ne peut jamais être modifiée (erreur de checksum), ce qui force la création de nouvelles migrations correctives
|
|
- **Synchronisation manuelle** : le fichier `consolidated_schema.sql` doit être mis à jour manuellement après chaque nouvelle migration
|
|
- **Pas de rollback** : les migrations sont unidirectionnelles (pas de `down`)
|
|
|
|
## Amendement #390 (2026-10-06)
|
|
|
|
Le schéma consolidé **crée** un profil secondaire, il ne le tient pas à jour. tauri-plugin-sql n'applique les migrations qu'à la base enregistrée par `add_migrations`, celle du profil par défaut (`simpl_resultat.db`). Jusqu'à #390, un profil secondaire gardait le schéma de la version qui l'avait créé. Depuis #390, un nouveau profil reçoit à sa création l'historique complet de `_sqlx_migrations`, et la commande `prepare_profile_db` applique à chaque ouverture les versions qui manquent à un profil secondaire. Voir l'[ADR 0021](0021-migrations-profils-secondaires.md). Les six migrations listées plus haut sont celles de 2025 ; il y en a dix-sept à la v0.17.0.
|