We're excited to share the 4.0.0
stable release today. 🎉
Prisma 4.0.0
features a variety of improvements across Prisma Migrate, Prisma schema, and Prisma Client. These changes will impact most Prisma users, particularly those who used some of our most popular Preview features around advanced index management, raw SQL queries, and filtering rows by properties of JSON.
As this is a major release, we included many breaking bug fixes and other enhancements, but we believe upgrading is worthwhile. You can learn about upgrading in our Prisma 4 Upgrade guide.
🌟 Help us spread the word about Prisma by starring the repo or tweeting about the release. 🌟
Major improvements
Here's a TL;DR:
- Preview features moved to General Availability
extendedIndexes
filterJson
improvedQueryRaw
- Improvements to the Prisma Schema
- Defaults values for scalar lists (arrays)
- Improved default support for embedded documents in MongoDB
- Explicit unique constraints for 1:1 relations
- Removed support for usage of
references
on implicit m:n relations - Enforcing uniqueness of referenced fields in the
references
argument in 1:1 and 1:m relations for MySQL - Removal of undocumented support for the
type
alias - Removal of the
sqlite
protocol for SQLite URLs - Better grammar for string literals
- New Prisma Client APIs
findUniqueOrThrow
findFirstOrThrow
- General improvements
- Deprecating
rejectOnNotFound
- Fix rounding errors on big numbers in SQLite
DbNull
,JsonNull
, andAnyNull
are now objects- Prisma Studio updates
- Dropped support for Node 12
- New default sizes for statement cache
- Renaming of
@prisma/sdk
npm package to@prisma/internals
- Removal of the internal
schema
property from the generated Prisma Client
- Deprecating
extendedIndexes
is now Generally Available
Starting with this release, we're excited to announce that extendedIndexes
is now Generally Available! 🚀
generator client {
provider = "prisma-client-js"
- previewFeatures = ["extendedIndexes"]
}
We introduced extendedIndexes
in 3.5.0
and have constantly been shipping improvements in the subsequent releases to the configuration of indexes.
You can now configure indexes in your Prisma schema with the The The @@index
attribute to define the kind of index that should be created in your database. You can configure the following indexes in your Prisma Schema:
Sort, sort order, and length
length
argument is available on MySQL on the @id
, @@id
, @unique
, @@unique
, and @@index
fields. It allows Prisma to support indexes and constraints on String
with a TEXT
native type and Bytes
types.
sort
argument is available for all databases on the @unique
, @@unique
, and @@index
fields. SQL Server also allows it on @id
and @@id
.
datasource db {
provider = "mysql"
url = env("DATABASE_URL")
}
model Post {
title String @db.VarChar(300)
abstract String @db.VarChar(3000)
slug String @unique(sort: Desc, length: 42) @db.VarChar(3000)
author String
created_at DateTime
@@id([title(length: 100), abstract(length: 10)])
@@index([author, created_at(sort: Desc)])
}
Hash indexes for PostgreSQL
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model A {
id Int @id
value Int
@@index([value], type: Hash)
}
GIN
, GiST
, SP-GiST
and BRIN
indexes for PostgreSQL
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model Post {
id Int @id
title String
content String?
tags Json?
@@index([tags], type: Gin)
}
SQL Server index clustering
datasource db {
provider = "sqlserver"
url = env("DATABASE_URL")
}
model Post {
id Int @default(autoincrement()) @id(clustered: false)
title String
content String?
}
Refer to our docs to learn how you can configure indexes in your Prisma schema and the supported indexes for the different databases.
⚠️ Breaking change: If you previously configured the index properties at the database level, refer to the upgrade guide for a detailed explanation and steps to follow.
filterJson
is now Generally Available
This release moves the filterJson
Preview feature into General Availability! 🪄
generator client {
provider = "prisma-client-js"
- previewFeatures = ["filterJson"]
}
JSON filtering allows you to filter rows by the data inside a Json
type. For example:
const getUsers = await prisma.user.findMany({
where: {
petMeta: {
path: ['cats', 'fostering'],
array_contains: ['Fido'],
},
},
})
The filterJson
Preview feature has been around since May 2021, and we're excited to mark it ready for production use! Learn more in our documentation.
improvedQueryRaw
is now Generally Available
Prisma 4 now marks the improvedQueryRaw
Preview feature as Generally Available! 🤩
generator client {
provider = "prisma-client-js"
- previewFeatures = ["improvedQueryRaw"]
}
This change introduces two major improvements (both breaking, refer to the upgrade guide for a smooth upgrade) when working with raw queries with Prisma:
Raw queries now deserialize scalar values to their corresponding JavaScript types.
Note: Types are inferred from the values and not from the Prisma Schema types.
Here's an example query and response:
Below is a table that recaps the serialization type-mapping for raw results:
Previously, PostgreSQL type-casts were broken. Here's an example query that used to fail:
You can now perform some type-casts in your queries as follows:
A consequence of this fix is that some subtle implicit casts are now handled more strictly and would fail. Here's an example that used to work but won't work anymore:
The
1. Scalar values are de-serialized as their correct JavaScript types
const res = await prisma.$queryRaw`SELECT bigint, bytes, decimal, date FROM "Table";`
console.log(res)
// [{ bigint: BigInt("123"), bytes: Buffer.from([1, 2]), decimal: new Prisma.Decimal("12.34"), date: Date("<some_date>") }]
Database Type
JavaScript Type
Text
String
Int32
Number
Int64
BigInt
Float
Number
Double
Number
Numeric
Decimal
Bytes
Buffer
Json
Object
DateTime
Date
Date
Date
Time
Date
Uuid
String
Xml
String
2. PostgreSQL type-casts
await prisma.$queryRaw`SELECT ${1.5}::int as int`;
// Before: db error: ERROR: incorrect binary data format in bind parameter 1
// After: [{ int: 2 }]
await prisma.$queryRaw`SELECT ${2020}::float4, (NOW() - ${"1 day"}::interval), ${"2022-01-01 00:00:00"}::timestamptz;`
await prisma.$queryRaw`SELECT LENGTH(${42});`
// ERROR: function length(integer) does not exist
// HINT: No function matches the given name and argument types. You might need to add explicit type casts.
LENGTH
PostgreSQL function only accept text
as input. Prisma used to silently coerce 42
to text
but won’t anymore. As suggested by the hint, cast 42
to text
as follows:
await prisma.$queryRaw`SELECT LENGTH(${42}::text);`
Refer to our docs to learn more on raw query type mappings in Prisma.
⚠️ Breaking change: To learn how you can smoothly upgrade to version 4.0.0
, refer to our upgrade guide: Raw query type mapping: scalar values are now deserialized as their correct JavaScript types and Raw query mapping: PostgreSQL type-casts.
Defaults values for scalar lists (arrays)
Prisma 4 now introduces support for defining default values for scalar lists (arrays) in the Prisma schema.
You can define default scalar lists as follows:
model User {
id Int @id @default(autoincrement())
posts Post[]
favoriteColors String[] @default(["red", "blue", "green"])
}
To learn more about default values for scalar lists, refer to our docs.
⚠️ Breaking change: Refer to the upgrade guide for a detailed explanation and steps to follow.
Improved default support for embedded documents in MongoDB
From version 4.0.0
, you can now set default values on embedded documents using the @default
attribute. Prisma will provide the specified default value on reads if a field is not defined in the database.
You can define default values for embedded documents in your Prisma schema as follows:
model Product {
id String @id @default(auto()) @map("_id") @db.ObjectId
name String @unique
photos Photo[]
}
type Photo {
height Int @default(200)
width Int @default(100)
url String
}
Refer to our docs to learn more on default values for required fields on composite types.
⚠️ Breaking change: Refer to our upgrade guide for detailed explanation and steps when working with default fields on composite types in MongoDB from version 4.0.0
.
Explicit unique constraints for 1:1 relations
From version 4.0.0
, 1:1 relations are now required to be marked with the @unique
attribute on the side of the relationship that contains the foreign key.
Previously, the relation fields were implicitly treated as unique under the hood. The field was also added explicitly when npx prisma format
was run.
model User {
id Int @id @default(autoincrement())
profile Profile? @relation(fields: [profileId], references: [id])
profileId Int? @unique // <-- include this explicitly
}
model Profile {
id Int @id @default(autoincrement())
user User?
}
⚠️ Breaking change: Refer to our upgrade path for a detailed explanation and steps to follow.
Removed support for usage of references
on implicit m:n relations
This release removes the usage of the references
argument, which was previously optional when using m:n relations.
model Post {
id Int @id @default(autoincrement())
- categories Category[] @relation("my-relation", references: [id])
+ categories Category[] @relation("my-relation")
}
model Category {
id Int @id @default(autoincrement())
- posts Post[] @relation("my-relation", references: [id])
+ posts Post[] @relation("my-relation")
}
This is because the only valid value for references
was id
, so removing this argument clarifies what can and cannot be changed.
Refer to our docs to learn more about implicit m:n relations.
⚠️ Breaking change: Refer to the upgrade guide for a detailed explanation and steps to follow.
Enforcing uniqueness of referenced fields in the references
argument in 1:1 and 1:m relations for MySQL
From version 4.0.0
, Prisma will now enforce that the field on the references
side of a @relation
is unique when working with MySQL.
To fix this, add the @unique
or @id
attributes to foreign key fields in your Prisma schema.
⚠️ Breaking change: To learn how to upgrade to version 4.0.0
, refer to our upgrade guide.
Removal of undocumented support for the type
alias
With 4.0.0
, we're deprecating the type
keyword for string aliasing. The type
keyword will now be exclusively used for defining embedded documents in MongoDB.
We encourage you to remove any usage of the type
keyword from your Prisma schema for type aliasing.
Removal of the sqlite
protocol for SQLite URLs
Starting from 4.0.0
, we are dropping support of the sqlite://
URL prefix for SQLite. We encourage you to use the file://
prefix when working with SQLite.
Better grammar for string literals
String literals in the Prisma schema now need to follow the same rules as strings in JSON. That changes mostly the escaping of some special characters.
You can find more details on the specification here:
To fix this, resolve the validation errors in your Prisma schema or run npx prisma db pull
to get the current values from the database.
⚠️ Breaking change: To learn how to update your existing schema, refer to the upgrade guide.
New Prisma Client APIs: findUniqueOrThrow
and findFirstOrThrow
In this release, we're introducing two new APIs to Prisma Client:
findUniqueOrThrow
– retrieves a single record asfindUnique
but returnsRecordNotFound
exception when no record is not foundfindFirstOrThrow
– retrieves the first record in a list asfindFirst
but returns aRecordNotFound
exception when no record is found
Here's an example of usage of the APIs:
const user = await prisma.user.findUniqueOrThrow({
where: {
email: "alice@prisma.io",
},
})
user.email // You don't need to check if the user is null
The APIs will be convenient for scripts API routes where you're already handling exceptions and want to fail fast.
Note: Please use the APIs with care. If you use these APIs, add the proper guardrails to your application.
Refer to the API reference in our docs to learn how findUniqueOrThrow
and findFirstOrThrow
differ from findUnique
and findFirst
respectively.
Deprecating rejectOnNotFound
We're deprecating the rejectOnNotFound
parameter in favor of the new findUniqueOrThrow
and findFirstOrThrow
Prisma Client APIs.
We expect the new APIs to be easier to understand and more type-safe.
Refer to the findUniqueOrThrow
and findFirstOrThrow
docs to learn how you can upgrade.
Fix rounding errors on big numbers in SQLite
SQLite is a loosely-typed database. While Prisma will prevent you from inserting values larger than integers, nothing prevents SQLite from accepting big numbers. These manually inserted big numbers cause rounding errors when queried.
Prisma will now check numbers in the query's response to verify they fit within the boundaries of an integer. If a number does not fit, Prisma will throw a P2023
error:
Inconsistent column data: Conversion failed:
Value 9223372036854775807 does not fit in an INT column,
try migrating the 'int' column type to BIGINT
To learn more on rounding errors with big numbers on SQLite, refer to our docs.
DbNull
, JsonNull
, and AnyNull
are now objects
Previously, Prisma.DbNull
, Prisma.JsonNull
, and Prisma.AnyNull
used to be implemented using string constants. This meant their types overlapped with regular string data that could be stored in JSON fields.
We've now made them special objects instead that don't overlap with string types.
Before 4.0.0
DbNull
was checked as a string so you could accidentally check for a null as follows:
import { PrismaClient, Prisma } from '@prisma/client'
const prisma = new PrismaClient()
const dbNull = "DbNull" // this string could come from anywhere!
await prisma.log.findMany({
data: {
meta: dbNull,
},
})
Expand to view the underlying Prisma schema
model Log {
id Int @id
meta Json
}
Prisma 4 resolves this using constants guaranteed to be unique to prevent this kind of inconsistent queries.
You can now read, write, and filter JSON fields as follows:
import { PrismaClient, Prisma } from '@prisma/client'
const prisma = new PrismaClient()
await prisma.log.create({
data: {
meta: Prisma.DbNull,
},
})
We recommend you double-check queries that use Json
after upgrading to Prisma 4. Ensure that you use the Prisma.DbNull
, Prisma.JsonNull
, and Prisma.AnyNull
constants from Prisma Client, not string literals.
Refer to the Prisma 4 upgrade guide in case you run into any type errors.
Prisma Studio updates
We've refined the experience when working with Prisma Studio with the following changes:
- Including a confirmation dialog before deleting records
- Adding a shortcut copy action on a cell – CMD + C on MacOS or Ctrl + C on Windows/ Linux
Dropped support for Node 12
The minimum version of Node.js Prisma will support is 14.17.x
. If you're using an earlier version of Node.js, you will need to update your Node.js version.
Refer to our system requirements for the minimum versions Prisma requires
New default sizes for statement cache
We had inconsistent and large default values (500 for PostgreSQL and 1000 for MySQL) for the statement_cache_size
. The new shared default value is 100.
If the new default doesn't work for you, please create an issue and use the statement_cache_size=x
parameter in your connection string to override the default value.
Renaming of @prisma/sdk
npm package to @prisma/internals
The internal package @prisma/sdk
is now available under the new, more explicit name @prisma/internals
.
We do not provide any API guarantees for @prisma/internals
as it might need to introduce breaking changes from time to time, and it does not follow semantic versioning.
This is technically not a breaking change as usage of the sdk
package is neither documented nor supported.
If you are using this package, it would be helpful if you could help us understand where, how, and why you are using it.
If you're using @prisma/internals
, please give feedback in this GitHub discussion. Your feedback will be valuable to us in defining a better API.
Removal of the internal schema
property from the generated Prisma Client
We've removed the internal Prisma.dmmf.schema
to reduce the size of Prisma Client generated and improve boot times.
To access the schema
property, you can use the getDmmf()
method from @prisma/internals
.
Fixes and improvements
Prisma
- PSL: define the grammar of string literals
- MySQL: Update default
statement_cache_size
- You cannot define an index on fields with Native type Text of MySQL.
- Removal of undocumented support for
type
alias with Prisma 4.0.0 @unique
is added during Re-Introspection- [PSL] Do not allow
references
arg on Many2Many relations on SQL - prisma migrate dev will not allow for db level default on scalar list
- Postgres Single Quote Escaping Breaking Migrations
- [Epic]
extendedIndexes
GA - Remove preview feature
extendedIndexes
- Epic: Scalar List Defaults
- Implement scalar lists defaults proposal in PSL
- Implement scalar list defaults proposal in introspection
- Implement scalar list defaults proposal in migrations
- PANIC: called
Option::unwrap()
on aNone
value in query-engine/core/src/interpreter/query_interpreters/nested_read.rs:232:50 - Invalid
db pull
/db push
flow - Improve CLI output when using
db push
with MongoDB - DB Pull Error
- MongoDB composite index crashes
- Error: Error in migration engine. Reason: [migration-engine/core/src/commands/diff.rs:127:22] internal error: entered unreachable code: no provider, no shadow database url for migrations target
- Regression: Prisma 3.15.0 with macOS / Azure SQL Server errors at database connection
- Migrate internal duration/performance logging
- Fix CI support in prisma forks
- Allow setting the
length
prefix onUnsupported
fields on MySQL - CRDB: Handle unicode escaping in enum and string defaults in migrate/introspection
- Poor grammar and confusing language in Prisma CLI
- Datetime defaults: make sure we consume the whole expression
- @prisma/engine-core uses vulnerable
undici 5.1.1
package - getConfig/getDmmf: Clarify error messages on Rust panics
Prisma Client
- PANIC in libs/prisma-models/src/record.rs:161:30Invalid coercion encountered: ConversionFailure("Float(BigDecimal("519.05"))", "Decimal")
- Set array default
- Allow setting scalar list default values
- test(client): happy blog-env test has no assertion
- Avoid using magic string values for JsonNull/DbNull
PrismaClientInitializationError
is missing expected error code- Make the implicit unique constraints on 1:1 relations explicit
- PANIC: called
Result::unwrap()
on anErr
value: FieldNotFound { name: "upsert", model: "CcStructureUnit" } in query-engine/core/src/query_graph_builder/write/write_args_parser.rs:24:62 - Consider renaming the
@prisma/sdk
package to reduce confusion - PANIC: JSON target types only accept strings or numbers, found: {"bytes":"05010000000473436170"} in query-engine/connectors/sql-query-connector/src/filter_conversion.rs:542:22
- Cannot pass Prisma.empty to $executeRaw function
- Numerics in Postgres bigger than 2<<128 crash Prisma/Quaint
- Remove
sqlite:
for defining a sqlite url - PANIC: called
Option::unwrap()
on aNone
value in query-engine/core/src/interpreter/query_interpreters/nested_read.rs:232:50 - findMany broken with many relations to same entity
- PANIC: called
Option::unwrap()
on aNone
value in query-engine\core\src\interpreter\query_interpreters\nested_read.rs:232:50 - Large decimals cause panick
- Misleading Error for non-unique relation names
thread 'tokio-runtime-worker' panicked at 'called
Option::unwrap()on a
Nonevalue', /Users/runner/.cargo/git/checkouts/quaint-9f01e008b9a89c14/479e08a/src/connector/postgres/conversion/decimal.rs:81:39
- Implement scalar list defaults proposal in query engine and client
default(now())
on the same table sometimes yield different times
Language tools (e.g. VS Code)
Prisma Engines
Credits
Huge thanks to @shian15810, @zifeo, @ever0de, @givensuman, @peter-gy, @rushabhhere, @flatplate, @njmaeff, @tnzk, @DePasqualeOrg, @roboncode, @jacobhq 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, June 30 at 5 pm Berlin | 8 am San Francisco.