6.7 KiB
review.md — Journal des décisions EME
Ce fichier trace chaque étape réalisée et chaque choix technique, avec sa justification. Il est mis à jour au fil de l'avancement. Lecture du plus ancien (haut) au plus récent (bas).
Règles métier ->
docs/regles-metier/regles-gestion.md· Contexte ->CONTEXT.md· Plan ->TODO.md
Conventions et choix transverses
Ces décisions s'appliquent à tout le projet, sauf mention contraire.
| Décision | Pourquoi |
|---|---|
Statuts métier en String côté Prisma (pas d'enum natif) |
SQL Server ne supporte pas les enums Prisma. Les valeurs sont validées côté TypeScript via src/models/enums.ts. |
Timestamps automatiques : createdAt @default(now()), updatedAt @updatedAt |
Évite d'avoir à fournir ces valeurs manuellement ; updatedAt est géré par Prisma au runtime. |
actif Boolean @default(true) |
Une entité créée est active par défaut. |
@unique sur les identifiants fonctionnels |
Intégrité : un identifiant en double casse l'authentification / l'unicité métier. |
Champs nullable selon les cardinalités 0..1 du diagramme de classes |
Un champ non connu à la création (ex. date de retour) ou optionnel doit être NULL, sinon le workflow métier est bloqué. |
onDelete: NoAction, onUpdate: NoAction sur les données de traçabilité (Emprunt, Checklist, ChecklistElement, Anomalie, Historique) |
Ces données ne doivent jamais être supprimées/altérées automatiquement en cascade. Toute suppression sera explicite côté service. Évite aussi l'erreur SQL Server "multiple cascade paths". |
ERD tenu à jour en miroir du schéma (docs/conceptions/uml/ERD.md) |
La source de vérité doit refléter le code réel (nullable, UK, etc.). |
Workflow Git : commits sur develop uniquement |
master est figé ; develop reste toujours à jour de master (aucune divergence puisque master ne bouge plus). |
Process avant chaque migration : prisma format -> prisma validate -> npm run build -> migration |
Détecter toute erreur de schéma/typage avant de toucher la base. |
Note outillage — migrations en environnement non-interactif
prisma migrate dev se bloque quand il doit demander une confirmation (ex. ajout de contrainte @unique sur table existante) car le terminal est non-interactif.
Contournement utilisé : générer le SQL avec prisma migrate diff --from-config-datasource --to-schema ... --script, écrire le fichier de migration, puis appliquer avec prisma migrate deploy. Résultat strictement identique à migrate dev, sans perte de données.
En terminal interactif (VS Code), migrate dev fonctionne normalement (taper y).
Journal chronologique
Étape 0 — Audit initial
- Constat : Block 0 (bootstrap) terminé mais non coché ; schéma à 4/16 entités ; aucune migration ; aucun commit Git.
- Décision : compléter le schéma par petits blocs (et non d'un coup) pour valider/committer au fur et à mesure.
Étape 1 — Configuration des migrations Prisma
- Correction
DATABASE_URL(mot de passe désaligné avecDB_PASSWORD). - Découverte : Prisma 7 interdit
urldansschema.prisma-> la connexion vit dansprisma.config.ts. Ligneurlretirée du datasource.
Étape 2 — Modèles de référence (Campus, Role, Utilisateur, CategorieMateriel)
- Defaults + timestamps auto ajoutés sur Campus, Utilisateur, CategorieMateriel (Role n'a pas de timestamps -> non modifié).
@uniquesurRole.code,Utilisateur.microsoftId,Utilisateur.email.Utilisateur.classe-> nullable : unRESPONSABLEn'a pas de classe (seuls les étudiants en ont).- ERD mis à jour en miroir (
UK,nullable). - Choix laissé de côté : tailles
@db.NVarChar(n)(colonnes restées enNVARCHAR(1000)par défaut). À reconsidérer plus tard.
Étape 3 — Bloc A : Infrastructure (SallePret, PosteEmprunt) — commit d026b75
SallePretrattachée àCampus;PosteEmpruntrattaché àSallePret. Conforme à l'ERD.
Étape 4 — Bloc B : CarteEtudiante — commit dfa73cd
- Rattachée à
Utilisateur. - Dette notée :
qr_codedevrait être@unique(sert à l'identification, RG02) — non posé pour rester fidèle à l'ERD.
Étape 5 — Bloc C : Matériel (Materiel, Accessoire, MaterielAccessoire) — commit 0774ee3
- Table de liaison
MaterielAccessoire(sans timestamps, conforme ERD). - Dette notée :
@@unique([materielId, accessoireId])etMateriel.statut @default("DISPONIBLE").
Étape 6 — Bloc D : Transactions (Emprunt, Checklist, ChecklistElement) — commit 6908a2b
- Champs de retour/optionnels nullable :
dateRetourReelle,modeIdentificationRetour,commentaireDepart,commentaireRetour,Checklist.commentaire,ChecklistElement.commentaire.- Pourquoi : RG12 crée l'emprunt au départ ; les infos de retour n'existent pas encore. En
NOT NULL, la création serait impossible.
- Pourquoi : RG12 crée l'emprunt au départ ; les infos de retour n'existent pas encore. En
ChecklistElement.accessoireIdnullable : conforme au diagramme de classes (Accessoire "0..1"), un élément peut être un libellé libre sans accessoire catalogué.- Les 9 FK en
NoAction: traçabilité + évitement des cascade paths. - ERD mis à jour en miroir (champs annotés
nullable).
Étape 7 — Stratégie Git : branche develop
- Création de
developdepuismaster. Désormais tous les commits vont surdevelop;masterfigé au Bloc C.
Étape 8 — Bloc E : Suivi (Anomalie, Notification, Historique) — commit 0fc9f9e
- Schéma 16/16 complet.
- Nullable selon
0..1:Anomalie.traiteeParId(null tant que non pris en charge),observation,dateResolution;Notification.anomalieId; les 5 FK optionnelles d'Historique(un événement n'a pas toujours d'emprunt/matériel/etc.). - Double relation
AnomalieversUtilisateurnommée :@relation("AnomalieEtudiant")(étudiant concerné) et@relation("AnomalieResponsable")(responsable qui traite). - Defaults :
Anomalie.detecteeAutomatiquement @default(true),Notification.lu @default(false),Notification.dateCreation @default(now()). - Les 12 FK en
NoAction(traçabilité). NotificationetHistoriquesansupdatedAt(conforme ERD).- ERD mis à jour en miroir.
Dette technique en attente
À traiter ensemble plus tard (avec mise à jour ERD en miroir) :
CarteEtudiante.qr_code->@unique(identification, RG02)MaterielAccessoire->@@unique([materielId, accessoireId])(un accessoire une seule fois par matériel)Materiel.statut->@default("DISPONIBLE")(un matériel neuf est disponible, RG07)- Tailles de colonnes
@db.NVarChar(n)(actuellementNVARCHAR(1000)partout) - Block 1 : middleware d'erreurs global, logs, ESLint + Prettier, Swagger/OpenAPI
Dernière mise à jour : 2026-06-15 — Schéma 16/16, fin du Bloc E.