5.2.0

🌟 Help us spread the word about Prisma by starring the repo or tweeting about the release. 🌟

Highlights

Improved Prisma Client experience for Prisma Accelerate and Data Proxy

In this release, we’ve made the following improvements to Prisma Client when using Prisma Accelerate or Prisma Data Proxy:

• Prisma Client will now automatically determine how it should connect to the database depending on the protocol in the connection string. If the connection string starts with prisma://, Prisma Client will try to connect to your database using Prisma Accelerate or Prisma Data Proxy.

• Prisma Studio now works with Prisma Data Proxy and Prisma Accelerate.

• We’ve introduced a new --no-engine flag which will prevent a Query Engine file from being included in the generated Prisma Client. This flag will also help ensure the bundle size of your application remains small by excluding the Query Engine files from the generated Prisma Client.

  prisma generate --no-engine

  The --data-proxy and --accelerate flags have not been removed but are now aliases for the new --no-engine flag.

  We recommend using the --no-engine flag when generating Prisma Client that uses either Accelerate or Data Proxy.

Simplified connection string override in Prisma Client

This release simplifies the API used when programmatically overriding the connection string by introducing the datasourceUrl property in Prisma Client’s constructor. This means you do not have to use the datasource name defined in your Prisma schema.

const prisma = new PrismaClient({
  datasourceUrl: "postgresql://johndoe:randompassword@localhost:5432/mydb",
})

Query performance improvements

Continuing our work from 5.1.0 we made further performance improvements around the queries Prisma executes, targeting one-to-many relation fields and nested updates.

Use LIMIT in one-to-many relations on a single parent

In cases where there is a single parent with a one-to-many relation included (findFirst, findUnique, findMany({ take: 1 })), we now utilize LIMIT at the database level to restrict the number of related items returned instead of retrieving all related items into memory and performing a take in memory.

For situations where you have many related objects but only need a few, you should see a dramatic improvement in speed and memory usage.

Note: we are still working on bringing this improvement to other parts of Prisma Client in upcoming releases. If multiple parent records are returned, the previous behavior is used.

Further improvements for nested writes

Thanks to our introduction of using RETURNING in some cases in 5.1.0, we could now improve performance in nested writes by removing reload nodes. This will now result in one less query per relation traversed in a nested write. For more info, check out the pull request.

Prisma Client query

await prisma.post.update({
  where: { id: 1 },
  data: {
    comment: {
      update: { 
        data: {
          body: "Updated comment body"
        }
      }
    }
  },
  select: {
    id: true,
    title: true,
  }
})

Before v5.2.0

SELECT "Post"."id", "Post"."title" FROM "Post" WHERE ("Post"."id" = $1 AND 1=1) LIMIT $2 OFFSET $3
SELECT "Post"."id", "Post"."userId" FROM "Post" WHERE "Post"."id" = $1 OFFSET $2
SELECT "User"."id" FROM "User" WHERE (1=1 AND "User"."id" IN ($1)) OFFSET $2
SELECT "User"."id" FROM "User" WHERE ("User"."id" = $1 AND 1=1) LIMIT $2 OFFSET $3
SELECT "User"."id", "User"."commentId" FROM "User" WHERE "User"."id" = $1 OFFSET $2
SELECT "Comment"."id" FROM "Comment" WHERE (1=1 AND "Comment"."id" IN ($1)) OFFSET $2
UPDATE "Comment" SET "body" = $1 WHERE ("Comment"."id" = $2 AND 1=1) RETURNING "Comment"."id"
SELECT "Post"."id", "Post"."title" FROM "Post" WHERE "Post"."id" = $1 LIMIT $2 OFFSET $3

5.2.0 and later

SELECT "Post"."id", "Post"."title", "Post"."userId" FROM "Post" WHERE ("Post"."id" = $1 AND 1=1) LIMIT $2 OFFSET $3
SELECT "User"."id" FROM "User" WHERE (1=1 AND "User"."id" IN ($1)) OFFSET $2
SELECT "User"."id", "User"."commentId" FROM "User" WHERE ("User"."id" = $1 AND 1=1) LIMIT $2 OFFSET $3
SELECT "Comment"."id" FROM "Comment" WHERE (1=1 AND "Comment"."id" IN ($1)) OFFSET $2
UPDATE "Comment" SET "body" = $1 WHERE ("Comment"."id" = $2 AND 1=1) RETURNING "Comment"."id"
SELECT "Post"."id", "Post"."title" FROM "Post" WHERE "Post"."id" = $1 LIMIT $2 OFFSET $3

Fixes and improvements

Prisma Client

• CFW: Avoid including Query Engine when data proxy is enabled
• Local Prisma Studio does not work with Data Proxy
• Postinstall hook always generates non Data Proxy Prisma Client
• limit is gone when findUnique with include relation
• Cannot fetch data from service: include is not a function Error while using Next.js with Data Proxy
• take key doesn't work correctly for nested query that returns one item with its nested children
• Prisma Client Edge: environment variables are not working with the "new" Module Worker syntax for Cloudflare Workers
• Add documentation to "PrismaClient is unable to be run in the browser"
• Change how Data Proxy Client deals with unsupported preview features
• Custom Prisma Client output location breaks Prisma Data Proxy in NextJS
• GetPayload type error since 4.16.1 "Two different types with this name exist, but they are unrelated."
• Browser bundle: Unhandled Runtime Error when upgrading to 5.1.0 from 5.0.0
• Prisma Client: disconnect: true does not appear to delete the foreign key in the returned data
• Prisma Client errors with "TypeError: Cannot create proxy with a non-object as target or handler" when using result client extension with no needs and count method
• Upgrading from Prisma 5.0.0 -> 5.1.0 results in "TS2321: Excessive stack depth comparing types" error using mockDeep<PrismaClient>()
• Unnecessary reads for to-one nested updates
• Better error message if @prisma/client/edge can not find environment variable
• 5.1: Alias for old name for <Model>CountOutputTypeDefaultArgs does not exist
• Incorrect pagination for nested m2m chunked reads

Prisma Migrate

• RustPanic on prisma generate when Unsupported field defined in a Composite type
• Use PostgreSQL System Information Functions instead of manually joining fields
• Duplicate expression index comment whenever db pull is run

Credits

Huge thanks to @skyzh, @alula, @michaelpoellath, @RobertCraigie, @darthmaim, @Gerschtli, @andyjy, @mejiaej, @iurylippo, @mrazauskas, @Coder246, @RDIL for helping!