jsonProtocol changes
As of Prisma version 5.0.0, the new jsonProtocol
is the default. There are some changes that directly result from this change and a few changes that are related to the new protocol.
A full list of Prisma 5 changes can be found in our release notes.
jsonProtocol specific changes
Below are changes that result directly from the jsonProtocol
feature becoming the default in Prisma 5.
Removal of jsonProtocol Preview Feature
In Prisma 5, jsonProtocol
is the default and only protocol in Prisma. The jsonProtocol
Preview feature is no longer needed.
Prisma 4 and lower:
generator client {provider = "prisma-client-js"previewFeatures = ["jsonProtocol"]}
Prisma 5:
generator client {provider = "prisma-client-js"}
Improved error messages
Due to the switch to the new protocol, several error messages have been improved. For example, the following error message in Prisma 4 and below:
$Failed to validate the query: `Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.createOneUser.data.UserCreateInput.person.PersonCreateNestedOneWithoutUserInput.create`: Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.createOneUser.data.UserCreateInput.person.PersonCreateNestedOneWithoutUserInput.create.PersonCreateWithoutUserInput.hubspot_id`: A value is required but not set., Query parsing/validation error at `Mutation.createOneUser.data.UserCreateInput.person.PersonCreateNestedOneWithoutUserInput.create.PersonUncheckedCreateWithoutUserInput.hubspot_id`: A value is required but not set.], Query parsing/validation error at `Mutation.createOneUser.data.UserUncheckedCreateInput.person`: Field does not exist on enclosing type.]` at `Mutation.createOneUser.data`
becomes the following in Prisma 5:
$Invalid `prisma.user.create()` invocation in$/Users/prismo/projects/prisma/reproductions/workbench/index.ts:21:36$$ 18 const prisma = new PrismaClient()$ 19$ 20 for (const u of userData) {$→ 21 const user = await prisma.user.create({$ data: {$ email: "eugene.albright@gallaudet.edu",$ person: {$ create: {$ first_name: "William",$ last_name: "Albright",$ + hubspot_id: String$ }$ }$ }$ })$$Argument `hubspot_id` must not be null.
jsonProtocol related changes
Below are changes that are related to the switch to the new protocol. If you were using the jsonProtocol
Preview Feature, you most likely ran into these issues.
Removal of array shortcuts
Several array shortcuts were removed as a part of this major update. These shortcuts were a way to add a single element as a value to an array-based operator.
OR operators
The following code in Prisma 4 and lower:
prisma.user.findMany({where: {OR: { email: 'foo@example.com' },},})
Will need to be changed to the following in Prisma 5:
prisma.user.findMany({where: {OR: [{ email: 'foo@example.com' }],},})
OR
operators will only accept array values.
in and notIn operators
Similar to OR
, in
and notIn
require array values.
Prisma 4 and lower:
prisma.user.findMany({where: {id: { in: 123 },},})prisma.user.findMany({where: {id: { notIn: 123 },},})
Prisma 5:
prisma.user.findMany({where: {id: {in: [123],},},})prisma.user.findMany({where: {id: {notIn: [123],},},})
If your in
and notIn
values are only one element, you can also update your code to not use these operators at all:
prisma.user.findMany({where: {id: 123,},})prisma.user.findMany({where: {id: { not: 123 },},})
path argument for filtering on JSON fields in PostgreSQL
When filtering on JSON fields in a PostgreSQL model the path
argument now only accepts an array.
When using the following schema:
model User {id String @idsettings Json}
Prisma 4 and lower:
prisma.user.findMany({where: {settings: {path: 'someSetting',equals: someValue,},},})
Prisma 5:
prisma.user.findMany({where: {settings: {path: ['someSetting'],equals: someValue,},},})
Note: This path
argument change only affects PostgreSQL databases. MySQL databases are not affected as they use a different syntax.
Scalar lists
Scalar list values must be arrays in all operations.
With the following schema:
model Post {id String @id @default(uuid())tags String[]}
Prisma 4 and lower:
prisma.post.create({data: {tags: 'databases',},})prisma.post.findMany({where: {tags: 'databases',},})
Prisma 5:
prisma.post.create({data: {tags: ['databases'],},})prisma.post.findMany({where: {tags: ['databases'],},})
Composite lists
Operations on lists of Composite types (for MongoDB) now only accept array values.
With the following schema:
model Post {id String @id @default(uuid())commentsList Comment[]}type Comment {text String}
Prisma 4 and lower:
prisma.post.findMany({where: {commentsList: {equals: { text: 'hello' },},},})
Prisma 5:
prisma.post.findMany({where: {commentsList: {equals: [{ text: 'hello' }],},},})
If you use the shorthand notation and exclude equals
, you still must supply an array value for composite list fields.
Prisma 4 and lower:
prisma.post.create({data: {commentsList: { text: 'hello' },},})prisma.post.findMany({where: {commentsList: { text: 'hello' },},})
Prisma 5:
prisma.post.create({data: {commentsList: [{ text: 'hello' }],},})prisma.post.findMany({where: {commentsList: [{ text: 'hello' }],},})