bd484db48a
Table QuestionThemeMonthly (instance, mois, thème, compteur). C'est elle qui rend tenable le §8.4 des CGU : le regroupement vivait dans ThemeId, colonne de la ligne VisitorQuestion, donc la purge du 90e jour l'emportait avec la question et le client perdait tout au 91e. Elle ne porte que des compteurs — aucune donnée personnelle, ce qui est précisément ce qui l'autorise à survivre. Insights lit désormais les thèmes dans cette table, pas dans les questions de la fenêtre. Liste fixe de 8 thèmes, pas de thèmes découverts par l'IA : des libellés régénérés à chaque passage donneraient « Horaires » en janvier et « Questions d'horaires » en février, deux lignes distinctes et une courbe qui ne veut rien dire — alors que la table existe pour porter cet historique. Le job tourne à 2 h, la purge à 3 h 30 : une question purgée avant d'avoir été classée ne compte dans aucun agrégat et rien ne peut la rattraper. Le plafond de 500 par passage ne perd rien, il retarde — les plus anciennes d'abord, un passage par jour, avertissement si le retard dépasse un passage. Les jetons ne sont pas décomptés du quota client : il n'a pas demandé ces appels. Un lot en échec n'est pas marqué « Autre » pour s'en débarrasser, ce serait une perte définitive maquillée en résultat ; et la relecture se fait par numéro, jamais par position, pour qu'une ligne manquante ne décale pas les suivantes. Instance.IsVisitorQuestionCollectionEnabled (défaut true) + garde dans Chat : le client est responsable de traitement, la collecte était inconditionnelle. Ajout d'une fabrique design-time : EF construisait tout l'hôte pour trouver le contexte, et l'hôte ouvre une connexion au démarrage — générer une migration exigeait donc une base joignable, impossible sur une machine sans Postgres ni Docker. dotnet test : 211 passés, 15 sautés, 0 échec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
39 lines
1.6 KiB
C#
39 lines
1.6 KiB
C#
using Microsoft.AspNetCore.Http;
|
|
using Microsoft.EntityFrameworkCore;
|
|
using Microsoft.EntityFrameworkCore.Design;
|
|
using System;
|
|
|
|
namespace ManagerService.Data
|
|
{
|
|
/// <summary>
|
|
/// Fabrique utilisée **uniquement par les outils EF** (`dotnet ef migrations add`).
|
|
///
|
|
/// ⚠️ Sans elle, EF construit tout l'hôte pour trouver le contexte — et l'hôte ouvre une
|
|
/// connexion PostgreSQL au démarrage (stockage Hangfire). Générer une migration exigeait
|
|
/// donc une base joignable, alors qu'écrire un fichier de migration n'a besoin d'aucune
|
|
/// base. Sur une machine sans Postgres ni Docker, c'était tout simplement impossible.
|
|
///
|
|
/// La chaîne de connexion n'est jamais utilisée pour se connecter à ce stade ; elle doit
|
|
/// seulement être syntaxiquement valide. <c>MIGRATIONS_CONNECTION</c> permet de la
|
|
/// surcharger pour un <c>database update</c> ponctuel.
|
|
/// </summary>
|
|
public class MyInfoMateDbContextFactory : IDesignTimeDbContextFactory<MyInfoMateDbContext>
|
|
{
|
|
public MyInfoMateDbContext CreateDbContext(string[] args)
|
|
{
|
|
var connectionString = Environment.GetEnvironmentVariable("MIGRATIONS_CONNECTION")
|
|
?? "Host=localhost;Port=5432;Database=my_info_mate;Username=postgres;Password=postgres";
|
|
|
|
var options = new DbContextOptionsBuilder<MyInfoMateDbContext>()
|
|
.UseNpgsql(connectionString, o =>
|
|
{
|
|
o.UseNetTopologySuite();
|
|
o.UseVector();
|
|
})
|
|
.Options;
|
|
|
|
return new MyInfoMateDbContext(options, new HttpContextAccessor());
|
|
}
|
|
}
|
|
}
|