100 % local — vos données ne quittent jamais votre navigateur

JSON en Prisma — un modèle qui migre

Transformez un échantillon JSON en modèle Prisma. L’identifiant exigé de tout modèle est toujours là : prisma validate passe et la migration se lance.

Instantané Privé Zéro cookie

Entrée JSON

Sortie Prisma

Ce que fait cet outil

Un échantillon JSON devient un modèle Prisma.

{ "id": 1, "name": "Ada", "tags": ["admin"], "score": 9.5 }
model Root {
  id    Int      @id
  name  String
  tags  String[]
  score Float
}

Le modèle seul n’est pas un schema.prisma : un fichier qui fonctionne a aussi un bloc datasource et un bloc generator. Ils décrivent votre base et votre client, dont une charge JSON ne dit rien.

Tout modèle reçoit un identifiant

Prisma refuse un modèle sans @id (ou @@id) : prisma validate s’arrête là. Donc :

  • un id de type Int ou String devient l’identifiant ;
  • aucun id et il en est ajouté un : id Int @id @default(autoincrement()) ;
  • un id d’un autre type — flottant, booléen, objet imbriqué — est renommé et garde sa clé d’origine :
model Root {
  id   Int    @id @default(autoincrement())
  id2  Float  @map("id")
  name String
}

Ce dernier cas produisait un modèle sans aucun identifiant : du Prisma d’apparence valide que l’outil en ligne de commande rejette. Trouvé en écrivant cette page, puis corrigé.

Rien qui ressemble à une relation n’est inventé

Un objet imbriqué devient une colonne Json. Ç’aurait pu être une relation vers une autre table, et deviner reviendrait à inventer un modèle, une clé étrangère et un sens à partir d’un document. Même chose pour un tableau d’objets et pour un tableau hétérogène.

Une liste homogène de scalaires reçoit bien une liste native — String[], Int[] — qui existe sur PostgreSQL, CockroachDB et MongoDB. Sur MySQL ou SQLite, passez-la en Json : la sortie n’a pas de datasource, elle ne peut donc pas savoir laquelle vous employez.

Noms, nullabilité, et ce qu’un échantillon ne dit pas

Les noms de champs passent en camelCase, et @map conserve la clé d’origine dès que les deux diffèrent : content-type devient contentType @map("content-type") et le nom de votre colonne ne bouge pas. Deux clés qui donnent le même camelCase sont suffixées plutôt que fondues.

Seul null produit une colonne optionnelle, Json?. Tout le reste est obligatoire, parce que l’échantillon avait une valeur — et un échantillon est le mauvais endroit pour apprendre qu’une colonne est nullable. Le ? fait un caractère, et il vous revient.

Confidentiel par conception

Tout s’exécute localement dans votre navigateur en JavaScript. Vos données ne sont jamais envoyées sur un serveur, ce qui rend l’outil sûr pour des contenus sensibles, et il fonctionne hors ligne.

Questions fréquentes

D’où vient le `id Int @id @default(autoincrement())` ?
De la règle de Prisma : tout modèle exige un identifiant. Si votre échantillon a un `id` entier ou chaîne, c’est lui. Sinon un identifiant est ajouté, et un `id` d’un autre type est renommé avec `@map("id")` pour que la clé d’origine survive. Sans cela le modèle avait l’air correct et `prisma validate` le refusait.
Pourquoi mon objet imbriqué est-il une colonne `Json` plutôt qu’une relation ?
Parce qu’un échantillon ne peut pas montrer une relation. `{"author": {"name": "Ada"}}` peut être une clé étrangère vers une table `Author` ou un bloc qui appartient à la ligne. Inventer la table, la clé et le sens ferait trois suppositions. `Json` garde la donnée et vous laisse la modélisation, qui vous revient.
`String[]` ne compile pas sur MySQL. Pourquoi est-ce là ?
Parce qu’une liste homogène de scalaires a un type natif sur PostgreSQL, CockroachDB et MongoDB, et que Prisma l’écrit `String[]`. MySQL et SQLite n’ont pas de listes scalaires : passez le champ en `Json`. Le générateur ne peut pas connaître votre source de données — il n’y a aucun bloc `datasource` dans la sortie.

Convertisseurs associés