Comment corriger la génération par IA de relations Prisma invalides

Les agents IA génèrent des schémas Prisma avec des relations manquant de relations inverses, des actions référentielles erronées ou des types de champs incompatibles qui font échouer prisma validate et prisma migrate.

L’agent écrit un schéma Prisma avec des relations qui semblent correctes mais échouent prisma validate en raison de références inverses manquantes, d’incompatibilités de type ou de configurations multi-relations ambiguës.

Le symptôme

Une relation est déclarée sur un modèle sans sa contrepartie requise sur l’autre, ou le type du champ de clé étrangère ne correspond pas au type du champ référencé.

// schema.prisma — WRONG
model User {
  id    String @id @default(cuid())
  posts Post[]
}

model Post {
  id       String @id @default(cuid())
  authorId Int    // Int, but User.id is String — type mismatch
  // Missing: author User @relation(fields: [authorId], references: [id])
}

L’exécution de prisma validate produit :

Error: The relation field `posts` on model `User` is missing an opposite
relation field on the model `Post`.

Pourquoi cela se produit

L’agent écrit souvent un côté d’une relation et oublie d’ajouter l’autre, surtout dans les cas many-to-many ou d’auto-référence. Il copie également les types de champs de mémoire sans vérifier que authorId doit correspondre exactement au type de l’id référencé.

Comment le repérer

prisma validate ou prisma migrate dev échoue avec une erreur de relation.
Un modèle a un champ tableau (one-to-many) mais le modèle référencé n’a pas de clé étrangère scalaire ou d’attribut @relation.
Many-to-many utilise des tables de jointure explicites avec des types incompatibles.
Les modèles auto-référents (par exemple, arbres de catégories) n’ont qu’un seul côté de la paire @relation(name: "...").

Comment le corriger

Chaque relation doit avoir ses deux côtés déclarés. Les types scalaires de clés étrangères doivent correspondre exactement au type du champ référencé.

// schema.prisma — CORRECT
model User {
  id    String @id @default(cuid())
  posts Post[] // one-to-many: back-reference
}

model Post {
  id       String @id @default(cuid())
  authorId String                       // String, matches User.id
  author   User   @relation(fields: [authorId], references: [id], onDelete: Cascade)
}

Pour un arbre auto-référent :

model Category {
  id       String     @id @default(cuid())
  parentId String?
  parent   Category?  @relation("CategoryTree", fields: [parentId], references: [id])
  children Category[] @relation("CategoryTree")
}

[ ] Run "prisma validate" before "prisma migrate dev" — fix all errors first
[ ] Every @relation on model A has a matching field on model B
[ ] Foreign key scalar type matches the referenced @id type (String/Int/cuid)
[ ] Self-referential relations use a named @relation("name") on both sides
[ ] Explicit many-to-many join tables declare both foreign keys with onDelete
[ ] onDelete referential action is explicit (Cascade, Restrict, SetNull) — not left to default

Prompt de correction

This Prisma schema fails prisma validate. Fix every relation error: add the
missing back-reference fields, ensure all foreign key scalar types exactly match
the referenced @id type, give every self-referential relation a unique name on
both sides, and set explicit onDelete actions (Cascade for required relations,
SetNull for optional). Run prisma validate after each change until it passes.

Test

# Validate schema before attempting migration
npx prisma validate && echo "Schema OK" || echo "FAIL: schema invalid"

# Also check for type mismatches (Int fk -> String id is a common error)
grep -A3 "@relation" prisma/schema.prisma