Decide avec l'utilisateur avant la sortie du projet, en acceptant de repartir
d'une base vierge en production.
⚠ Aucune base anterieure n'est plus migrable : __EFMigrationsHistory d'une
installation existante contient les quinze anciens noms, et EF Core tenterait
de recreer des tables deja presentes. La mise a jour echouerait, et son retour
arriere aussi. La seule voie sur un serveur installe est remove --purge puis
reinstallation — sans le --purge, data_dir survit et l'ancienne base revient
avec son historique incompatible.
La fusion est verifiee, pas supposee : les deux schemas ont ete appliques sur
deux bases SQLite vierges puis compares. 97 colonnes identiques, 27 index
identiques, 11 cles etrangeres identiques avec leurs modes ON DELETE. Les deux
SET NULL, le RESTRICT des auteurs, les trois index uniques partiels et les deux
index qui cohabitent sur Prets.LivreId sont tous preserves.
Deux ecarts subsistent, sans effet : l'ordre physique des colonnes, et les
DEFAULT 0 de Role, TypeDocument et Rang, qui n'existaient que pour remplir les
lignes deja presentes lors d'un AddColumn.
Deux SQL de reprise de donnees disparaissent avec leurs migrations
(StatutPersonnelEtTableAuteurs, RangDesEnvies). MigrationRangDesEnviesTests, qui
migrait jusqu'a ListeDEnvies pour eprouver le second, n'a plus d'objet : 628
tests -> 626.
Verifie en execution sur une base creee de zero : creation d'un livre, recherche
sans accents, pret, et second pret refuse par l'index unique partiel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
