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>
2.9 KiB
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 :
- Schéma initial (13 tables, 9 index)
- Seed des catégories et mots-clés par défaut
- Ajout
has_headersurimport_sources - Ajout
is_inputablesurcategories - Création de
import_config_templates - 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.sqldoit ê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. Les six migrations listées plus haut sont celles de 2025 ; il y en a dix-sept à la v0.17.0.