Upgrade to jsonProtocol in Prisma 5

/ Guides / Upgrading / Upgrading versions / Upgrade to Prisma 5

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.

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],
    },
  },
})

Suggestion for single elements

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 @id
  settings 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' }],
    },
  },
})

Shorthand notation usage

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' }],
  },
})

Was this helpful?

Edit this page on GitHub

jsonProtocol changes

jsonProtocol specific changes

Removal of jsonProtocol Preview Feature

Improved error messages

Removal of array shortcuts

OR operators

in and notIn operators

path argument for filtering on JSON fields in PostgreSQL

Scalar lists

Composite lists

Was this helpful?

Product

Developers

Use Cases

Company

Newsletter

jsonProtocol changes

jsonProtocol specific changes

Removal of jsonProtocol Preview Feature

Improved error messages

jsonProtocol related changes

Removal of array shortcuts

OR operators

in and notIn operators

path argument for filtering on JSON fields in PostgreSQL

Scalar lists

Composite lists

Was this helpful?

Product

Developers

Use Cases

Company

Newsletter