@prisma/client 2.21.0 on Node.js NPM

Today, we are excited to share the 2.21.0 stable release 🎉

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

Major improvements & new features

Order by an aggregate in groupBy is now in Preview

Whew, that's a tongue-twister for a neat feature.

Let's say you want to group your users by the city they live in and then order the results by the cities with the most users. In 2.21.0, now you can!

const userRatingsCount = await prisma.user.groupBy({
  by: ['city'],
  count: {
    city: true,
  },
  orderBy: {
    _count: {
      city: 'desc',
    },
  },
})

Click to view the underlying model

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
  city  String
}

The query returns the following:

[
  { city: 'Berlin', count: { city: 3 } },
  { city: 'Paris', count: { city: 2 } },
  { city: 'Amsterdam', count: { city: 1 } },
]

Enable this feature with the orderByAggregateGroup preview flag:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["orderByAggregateGroup"]
}

📚 Documentation: Order by aggregate group

Breaking Changes

Aggregates are now nullable

Before 2.21.0, aggregations on nullable fields always returned 0, even when there was no record or if all aggregated records were nulls. Returning 0 for null values made it impossible to differentiate between these two different results.

We are changing aggregates to follow what the database returns:

All aggregated fields are now nullable. Aggregated fields can return null when there's either no record in the database or if all the aggregated records are null.
The only exception is count, which still returns 0, even if records are null or if there's no record.

For example, previously, if there's no record in the database or if all records are nulls, the following aggregation:

const result = await prisma.post.aggregate({
  sum: { amount: true },
})

Results in:

{
  sum: {
    amount: 0
  }
}

The result.sum type is currently of type { amount: number }.

Starting this release, the same query returns:

{
  sum: {
    amount: null
  }
}

And result.sum is of type { amount: number | null }

📚 Documentation: Aggregates are nullable

`disconnect` no longer throws an error on unconnected records

Prior to 2.21.0, if you ran the following code:

const user = await prisma.user.update({
  where: { email: 'bob@prisma.io' },
  data: {
    profile: {
      disconnect: true,
    },
  },
})

And no profile was connected to Bob, the client would throw with this error:

The records for relation `UserToProfile` between the `User` and `Profile` models are not connected.

We learned from you that handling this added unnecessary boilerplate to your applications. As of 2.21.0, we've removed this error. Now, if you try disconnecting an unconnected record, the operation does nothing and passes through.

This change is unlikely to affect you unless you explicitly handle the disconnect error. In that case, adjust your code because the command no longer throws an error.

📚 Documentation: $disconnect()

`@default(dbgenerated(""))` is no longer permitted

The dbgenerated() function allows you to define default values generated directly by the database and cannot yet be represented in the Prisma schema.

Previously, you could pass an empty string, i.e., @default(dbgenerated("")), which would fail since the contents are added into the migration SQL as columnName COLUMN_TYPE DEFAULT <contents of dbgenerated>

As of 2.21.0, if a value is present, it cannot be an empty string.

If you want an empty string default, the correct syntax is @default(dbgenerated("''") (or other quotation marks, depending on the database provider).

📚 Documentation: dbgenerated()

Fixes and improvements

Prisma Client

Prisma Migrate

On PostgreSQL, when changing column types that are also in an index, Migrate would generate a DROP COLUMN ..., ADD COLUMN ... sequence of SQL statements. These silently drop the indexes present on the column, and migrate would only re-create them with the next migration. With this release, the issue has been fixed, and Migrate recreates the index in the same migration.
Not prettified error This line is invalid. It does not start with any known Prisma schema keyword. in introspection for an invalid schema.
Improve error message in Prisma Migrate when a provider mismatch is detected
SQL Server Introspection fails on Tables with Geography Data Type
Error when introspecting Azure SQL Server database
db push crashes when used on specific Postgres connection string with non existing database
Migrate leaks database password when Migration Engine binary crashes
Changed the phrasing of error messages for P3006. It wrongly mentioned "temporary database", it's now been corrected to mentions the shadow database.

Prisma Studio

We worked on shipping some minor improvements and bug fixes:

prisma-engines

Credits

Huge thanks to @Sytten, @endor, @iBluemind, @schiller-manuel, @mongolyy, @matthewmueller, @paularah, @Iamshankhadeep, @meeq, @safinsingh, @darioielardi for helping!

📺 Join us for another "What's new in Prisma" livestream

Learn about the latest release and other news from the Prisma community by joining us for another "What's new in Prisma" livestream.

The stream takes place on Youtube on Thursday, April 15 at 5pm Berlin | 8am San Francisco.