AuditLog porte un UserId, et les valeurs avant/après d'une modification de User contiennent e-mail, prénom et nom : conservés sans limite jusqu'ici, quand VisitEvent purge à 13 mois et VisitorQuestion à 90 jours. Le plan l'assignait explicitement au lot J, il n'avait pas été fait. 12 mois, uniforme. Pas 13 : les 13 mois des statistiques existent pour comparer une saison à la précédente, les recopier ici serait du mimétisme — un test fige l'écart voulu. Écarté aussi : garder les suppressions plus longtemps que les créations, ça double les règles pour un cas qu'une sauvegarde couvre déjà. Inerte tant qu'Audit:RetentionDays n'est pas défini, même verrou que les VisitEvent : c'est une suppression définitive et le pg_dump n'est pas en place. Volontairement différent de VisitorQuestionPurgeService, qui tourne sans condition parce que ses 90 jours sont un engagement des CGU, pas un réglage. La suppression se teste contre un vrai Postgres : ExecuteDeleteAsync n'est pas traduisible par le provider InMemory, et l'écrire en chargeant les lignes puis RemoveRange l'aurait rendue testable en mémoire au prix de charger un an de journal — dégrader le code de production pour satisfaire un provider de test. dotnet test : 213 passés, 16 sautés, 0 échec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Migrations
Invite de commande
Ouvrir un invite de commande dans le répertoire de la solution
Supprimer la dernière migration
A faire uniquement si elle n'a pas encore été appliquée à la base de données
dotnet ef migrations remove
Ajouter une migration
dotnet ef migrations add
Mise à jour de la base de données
dotnet ef database update