prisma/prisma
Compare Source
Today, we are issuing the 2.1.1 patch release.
Fixes and improvements
prisma migrate
Compare Source
Today, we are issuing the 2.1.0 stable release.
Major improvements
Next to a lot of bug fixes, this version includes a number of new features.
Basic filtering on Json data in Prisma Client
When querying data, you can now perform basic filtering with Json fields using equal and not:
const jsonData = [
{
array1key: 'array1value',
},
]
// `equal` filter. Return all posts with this particular `jsonData`
const result = await prisma.post.findMany({
where: {
jsonData
},
})
// `not` filter. Return all posts, which don't have this `jsonData`
const result = await prisma.post.findMany({
where: {
jsonData: { not: jsonData }
},
})
Expand to view a Prisma schema for this example
A sample Prisma schema for the example above could look like this:
model Post {
id Int @​id @​default(autoincrement())
title String
content String?
jsonData Json
}
You can now hide the Prisma CLI update notifier message by setting the environment variable PRISMA_HIDE_UPDATE_MESSAGE (e.g. to "1", "true" or "asd").
export PRISMA_HIDE_UPDATE_MESSAGE="1"
Prepared statement caching for PostgreSQL
Under the hood, we enabled prepared statement caching for PostgreSQL. This way Prisma Client's query engine does not repeatedly prepare the same statement but can reuse an existing one which reduces database CPU usage and query latency.
Many bug fixes for Prisma VSCode Extension
The Prisma VSCode extension received an extraordinary number of tiny fixes this release, which will make using it much more pleasant. Give it a try!
Experimental features
With the GA release of Prisma 2.0, you can expect much more stable releases in the future. At the same time, we of course want to be able to release new features that are fresh from our developers for you to try out. This is the best way we can get them stable enough to be generally available.
We are doing this with experimental features.
๐จ The following features are not part of our official and stable API and may be changed or removed completely in a future release.
Enabling experimental features in Prisma Client
With this release, we introduce feature flags for Prisma Client. Similar to the --experimental flag in the CLI (for prisma studio and prisma migrate), this enables us to hide functionality from the default API that all users get when installing Prisma and Prisma Client. Instead, users can explicitly opt-in to certain features by enabling them via the new experimentalFeatures field on the Prisma Client generator definition in their Prisma schema.
The experimentalFeatures field can be set like this:
generator client {
provider = "prisma-client-js"
experimentalFeatures = ["connectOrCreate", "transactionApi"]
}
Read more below to learn about the connectOrCreate and transactionApi experimental features.
connectOrCreate
While Prisma Client already provides an upsert query, which is available on the top-level of the Prisma Client API, we now also support upserts in a nested manner. When writing data with Prisma Client, both in update and create, you can now provide an upsert operation on a related row by using connectOrCreate.
Example
In this example, we create a new post and connect it to an author with the email address [email protected]. If that author doesn't exist yet, create it with the name "Alice".
await prisma.post.create({
data: {
title: 'Prisma 2.1.0',
author: {
connectOrCreate: {
where: {
email: "[email protected]"
},
create: {
name: "Alice",
email: "[email protected]"
}
}
}
}
})
Feature flag
To enable connectOrCreate, you can use the feature flag connectOrCreate in your Prisma schema file:
generator client {
provider = "prisma-client-js"
experimentalFeatures = ["connectOrCreate"]
}
Please share your feedback on how this feature works for you. We are interested in both positive and negative feedback, so we know if this feature is already ready for production! (If encounter any problems, please open a new issue here).
transactionApi
While Prisma already ships transactions within nested writes, there are many use cases, where you might want to perform multiple unrelated write operations in a transaction and rollback, if one of them fails. By wrapping your write operations in the new transaction() function, you can achieve exactly this!
(Note, that these transactions are not long-running and are executed directly after each other. This is an explicit design decision of Prisma. In case this does not cover your use case yet, please chime in on GitHub).
Example
//run inside `async` function
await prisma.transaction([
prisma.user.create({
data: {
email: "[email protected]",
},
}),
prisma.user.create({
data: {
email: "[email protected]",
},
}),
])
Alternatively, you can store the unresolved promises in variables and pass these to the new transaction function:
const userOperation1 = prisma.user.create({
data: {
email: "[email protected]",
},
})
const userOperation2 = prisma.user.create({
data: {
email: "[email protected]",
},
})
//run inside `async` function
await prisma.transaction([userOperation1, userOperation2])
Feature flag
To enable the experimental transaction api, you can use the feature flag transactionApi in your Prisma schema file:
generator client {
provider = "prisma-client-js"
experimentalFeatures = ["transactionApi"]
}
Please leave feedback on how this feature works for you prisma/prisma-client-js#โ667. We are interested in both positive and negative feedback, so we know if this feature is already ready for production. (If there are problems you can also open a new issue here).
Enabling experimental features in the Prisma CLI
In the Prisma CLI, we are using dedicated experimental flags that can be added to any command.
Re-Introspection
One common problem when using Prisma is that manual changes to your Prisma schema are overwritten the next time you run prisma introspect. This version adds an experimental mode for this functionality where we try to keep some of these changes:
You enable this by supplying the --experimental-reintrospection flag to prisma introspect:
npx prisma introspect --experimental-reintrospection
Please leave feedback on how this feature works for you #โ2829. We are interested in both positive and negative feedback, so we know if this feature is already ready for production. (If there are problems you can also open a new issue at here).
Fixes and improvements
prisma
prisma-client-js
vscode
studio
prisma-engines
Compare Source
Today we release the first patch release 2.0.1.
This is the first time that we run our new patch process! And it looks like everything went well ๐ค.
Improvements
- The database detection in
prisma introspect got improved so there are fewer false positives that tell users their database is Prisma 1.
๐ Today, we are launching Prisma 2.0 for General Availability! Read the announcement to learn more.
๐ก What is Prisma 2.0?
Today's General Availability release features Prisma Client, a type-safe and auto-generated query builder for your database. Thanks to introspection, Prisma Client can be used for existing databases as well.
Note: Prisma Migrate and Prisma Studio are not part of today's release. They're still experimental.
๐ Getting started
The easiest way to get started is by following the Quickstart (5 min). It is based on a SQLite demo database and doesn't require any setup!
You can also connect Prisma to your own PostgreSQL or MySQL database, either in an existing project or when starting from scratch.
โ๏ธ Let us know what you think
As always, we very much appreciate your feedback! Please don't hesitate to reach out here on GitHub or on Slack if you have any questions, thoughts, or any other kind of feedback about Prisma! ๐
โฌ๏ธ Upgrading from Prisma 1
If you're currently using Prisma 1 and want to upgrade to the new version, you can start by learning about the upgrade process in the docs: How to upgrade ๐
If you have any questions or feedback about the upgrade process, please create a GitHub issue in our new feedback repo. You can also share your personal feedback path with us and we'll try to figure out the best way to upgrade with you!
We're also planning upgrade webinars, where we're demoing the upgrade process for different scenarios (e.g. using prisma-binding, Prisma Client, Nexus, ...). The webinars are currently planned for July, we'll announce the dates soon!
๐ Join us online for Prisma Day on June 25th and 26th
We're hosting another edition of Prisma Day this year and are going fully remote. Join us online for hands-on workshops on June 25th and great talks on June 26th. Some of the speakers include GitHub co-founder Tom Preston-Werner, Netlify CEO Mathias Biilmann Christensen and lots of Prisma folks to tell you the latest about Prisma 2.0.
Compare Source
Today, we are issuing the twenty-fifth Preview release: 2.0.0-preview025 (short: preview025).
Breaking changes
Renaming the prisma2 npm package
With this release, we're renaming the Prisma 2 CLI npm package from prisma2 to @prisma/cli. Note that you can still invoke the CLI using the prisma2 command!
To upgrade, you first should uninstall the current prisma2 version and then install the @prisma/cli package.
Local installation (recommended)
The local installation is generally preferred since it prevents conflicting versions of the same package.
##### Uninstall current `prisma2` CLI (`preview024` or earlier)
npm uninstall prisma2
##### Install new `prisma2` CLI via `@prisma/cli` npm package
npm install @​prisma/cli --save-dev
##### Invoke the CLI via `npx`
npx prisma2
Global installation
##### Uninstall current `prisma2` CLI (`preview024` or earlier)
npm uninstall -g prisma2
##### Install new `prisma2` CLI via `@prisma/cli` npm package
npm install -g @​prisma/cli
##### Invoke the CLI via `npx`
npx prisma2
Other
- The
prisma2 --version output changed
- Virtual relation fields (aka โback-relation fieldsโ) follow the same name as the model they relate to during introspection
- The default for
errorFormat in the PrismaClient constructor now is colorless
Fixes and improvements per Prisma 2 repository
prisma2
prisma-client-js
prisma-engines
migrate
Compare Source
Today, we are issuing the twenty-fourth Preview release: 2.0.0-preview024 (short: preview024).
Major improvements
Reduced size of Prisma Client & Azure functions support
This release contains major improvements for Prisma Client. It now supports Windows Azure functions. In addition to that, the generated Prisma Client code inside your node_modules directory now is a lot smaller.
Another improvement is a better debugging experience. When setting the DEBUG environment variable (e.g. with export DEBUG="*"), the logging output now contains the names of Prisma Client API calls.
Use relation fields as ID on a Prisma model
In this release, it's now possible to use relation fields of Prisma models as IDs. In "database-speak", this means that you can now have both a primary key and a foreign key constraint on the same column.
Reference a single-field ID
For example, a Movie could always be identified by its Director:
model Movie {
director Director @​id
title String
}
model Director {
id Int @​id @​default(@​autoincrement())
name String
}
This is what the corresponding SQL (in SQLite dialect) looks like:
CREATE TABLE "Movie" (
"director" INTEGER NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("director"),
FOREIGN KEY ("director") REFERENCES "Director"("id")
);
CREATE TABLE "Director" (
"id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
"name" TEXT NOT NULL DEFAULT ''
);
Expand to view an example for creating `Movie`s and `Director`s in Prisma Client
Nested write to create Movie with Director:
// Run inside `async` function
const movie = await prisma.movie.create({
data: {
title: "Hello World",
director: {
create: {
name: "Alice"
}
}
},
})
Nested write to create Director with Movie:
// Run inside `async` function
const director = await prisma.director.create({
data: {
name: "Bob",
movies: {
create: [{
title: "Hello World"
}]
}
},
})
You can also create a relation to a multi-field ID:
model Movie {
director Director @​id @​map(["firstName", "lastName"])
title String
}
model Director {
firstName String
lastName String
@​@​id([firstName, lastName])
}
Note that in this case, the Movie table in the underlying database will actually have two physical columns called firstName and lastName. These are referencing the respective firstName and lastName column on the Director table.
Here is what the above models correspond to in SQL:
CREATE TABLE "Movie" (
"firstName" TEXT NOT NULL ,
"lastName" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName"),
FOREIGN KEY ("firstName","lastName") REFERENCES "Director"("firstName","lastName")
);
CREATE TABLE "Director" (
"firstName" TEXT NOT NULL DEFAULT '' ,
"lastName" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName")
);
In many cases, it might make sense to name the columns on Movie differently. For example, they could be called directorFirstName and directorLastName. This can be achieved via adding the @map attribute to the field:
model Movie {
director Director @​id @​map(["directorFirstName", "directorLastName"]) @​relation(references: [firstName, lastName])
title String
}
model Director {
firstName String
lastName String
@​@​id([firstName, lastName])
}
Note that in this case you could also omit the @relation attribute, the result would be the same:
model Movie {
director Director @​id @​map(["directorFirstName", "directorLastName"])
title String
}
model Director {
firstName String
lastName String
@​@​id([firstName, lastName])
}
In this case, the field names in @map on Movie get matched with the field names in @@​id on Director.
Both cases correspond to the following SQL:
CREATE TABLE "Movie" (
"directorFirstName" TEXT NOT NULL ,
"directorLastName" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("directorFirstName","directorLastName"),
FOREIGN KEY ("directorFirstName","directorLastName") REFERENCES "Director"("firstName","lastName")
);
CREATE TABLE "Director" (
"firstName" TEXT NOT NULL DEFAULT '' ,
"lastName" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName")
);
Expand to view an example for creating `Movie`s and `Director`s in Prisma Client
Nested write to create Movie with Director:
// Run inside `async` function
const movie = await prisma.movie.create({
data: {
title: 'Hello World',
director: {
create: {
firstName: 'Alice',
lastName: 'Allen',
},
},
},
})
Nested write to create Director with Movie:
// Run inside `async` function
const director = await prisma.director.create({
data: {
firstName: 'Bob',
lastName: 'Nolan',
movies: {
create: [
{
title: 'Hello World',
},
],
},
},
})
You can also create a multi-field ID on a model that contains a relation field:
model Movie {
director Director
title String
@​@​id([director, title])
}
model Director {
id String @​id @​default(cuid())
name String
}
This corresponds to the following SQL:
CREATE TABLE "Movie" (
"director" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("director","title"),
FOREIGN KEY ("director") REFERENCES "Director"("id")
);
CREATE TABLE "Director" (
"id" TEXT NOT NULL ,
"name" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("id")
);
Expand to view an example for creating `Movie`s and `Director`s in Prisma Client
Nested write to create Movie with Director:
// Run inside `async` function
const movie = await prisma.movie.create({
data: {
title: 'Hello World',
director: {
create: {
name: 'Alice',
},
},
},
})
Nested write to create Director with Movie:
// Run inside `async` function
const director = await prisma.director.create({
data: {
name: 'Bob',
movies: {
create: [
{
title: 'Hello World 2',
},
],
},
},
})
You can also define a multi-field ID on a model which contains a relation field that targets a model with a multi-field ID:
model Movie {
director Director
title String
@​@​id([director, title])
}
model Director {
firstName String
lastName String
@​@​id([firstName, lastName])
}
This is what the above code translates to in SQL:
CREATE TABLE "Movie" (
"director_firstName" TEXT NOT NULL ,
"director_lastName" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("director_firstName","director_lastName","title"),
FOREIGN KEY ("director_firstName","director_lastName") REFERENCES "Director"("firstName","lastName")
);
CREATE TABLE "Director" (
"firstName" TEXT NOT NULL DEFAULT '' ,
"lastName" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName")
);
Similar to the case before, you can also give names to the added columns on Movie by using the @map attributed:
model Movie {
director Director @​map(["directorFirstName", "directorLastName"]) @​relation(references: [firstName, lastName])
title String
@​@​id([director, title])
}
model Director {
firstName String
lastName String
@​@​id([firstName, lastName])
}
And as before you can also omit the @relation attribute in this scenario:
model Movie {
director Director @​map(["directorFirstName", "directorLastName"])
title String
@​@​id([director, title])
}
model Director {
firstName String
lastName String
@​@​id([firstName, lastName])
}
In both cases, the models correspond to the following tables:
CREATE TABLE "Movie" (
"directorFirstName" TEXT NOT NULL ,
"directorLastName" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("directorFirstName","directorLastName","title"),
FOREIGN KEY ("directorFirstName","directorLastName") REFERENCES "Director"("firstName","lastName")
);
CREATE TABLE "Director" (
"firstName" TEXT NOT NULL DEFAULT '' ,
"lastName" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName")
);
Expand to view an example for creating `Movie`s and `Director`s in Prisma Client
Nested write to create Movie with Director:
// Run inside `async` function
const movie = await prisma.movie.create({
data: {
title: 'Hello World',
director: {
create: {
firstName: 'Alice',
lastName: 'Allen',
},
},
},
})
Nested write to create Director with Movie:
// Run inside `async` function
const director = await prisma.director.create({
data: {
firstName: 'Bob',
lastName: 'Nolan',
movies: {
create: [
{
title: 'Hello World',
},
],
},
},
})
MODELGetSelectPayload and MODELGetIncludePayload have been merged into MODELGetPayload. More info here.
Fixes and improvements per Prisma 2 repository
prisma2
migrate
prisma-client-js
prisma-engines
Compare Source
Today, we are issuing the ninth Beta release: 2.0.0-beta.9 (short: beta.9).
Enforcing arrays in OR
We used to allow this syntax:
const orIncorrect = await prisma.post.findMany({
orderBy: {
id: 'asc'
},
where: {
OR: {
title: {
equals: "Prisma makes databases easy"
},
authorId: {
equals: 2
}
}
}
});
However, the thing that we want is this:
const orCorrect = await prisma.post.findMany({
orderBy: {
id: 'asc'
},
where: {
OR: [{
title: {
equals: "Prisma makes databases easy"
},
}, {
authorId: {
equals: 2
}
}]
}
})
So only the array syntax makes sense, therefore we also only allow that from now on.
Fixes and improvements
prisma
prisma-client-js
vscode
prisma-engines
Credits
Huge thanks to @โSytten for helping!
Compare Source
Today, we are issuing the eighth Beta release: 2.0.0-beta.8 (short: beta.8).
Breaking change: Splitting .raw into .queryRaw and .executeRaw
When dealing with raw SQL queries, there are two things we care about - the "return payload", which is being calculated by the SELECT statement we use and the number of affected rows - if we for example do an UPDATE query.
Until now, Prisma Client decided under the hood with a heuristic, when to return the number of affected rows and when to return the result data.
This heuristic broke if you wanted the opposite of what the heuristic returned.
That means that the decision has to be made by the developer using Prisma Client instead.
Therefore, we remove the raw command and replace it with executeRaw and queryRaw.
So what does return what?
executeRaw returns the number of affected rowsqueryRaw returns the result data
The heuristic used to return the data for SELECT statements. So if you upgrade to Beta 8, you need to use queryRaw for your SELECT statements and executeRaw for all SQL queries, which mutate data.
The rule of thumb is: Do not use executeRaw for queries that return rows.
In Postgres, it will work to use executeRaw('SELECT 1), however, SQLite will not allow that.
Fixes and improvements
prisma
prisma-client-js
Credits
Huge thanks to @โSytten, @โmerelinguist for helping!
Compare Source
Today, we are issuing the seventh Beta release: 2.0.0-beta.7 (short: beta.7).
New Pagination
Prisma Client's pagination has been simplified a lot!
- Removed
first, last, before, after arguments.
- Added
cursor and take arguments.
skip argument unchanged.
The take argument replaces first and last.
Examples
first
prisma.user.findMany({
first: 10
})
// becomes
prisma.user.findMany({
take: 10
})
last
prisma.user.findMany({
last: 10
})
// becomes
prisma.user.findMany({
take: -10
})
before
prisma.user.findMany({
before: "someid"
first: 10
})
// becomes
prisma.user.findMany({
cursor: "someid"
take: -10
skip: 1
})
after
prisma.user.findMany({
after: "someid"
first: 10
})
// becomes
prisma.user.findMany({
cursor: "someid"
take: 10
skip: 1
})
The record specified with cursor is now included in the results, making skip: 1 necessary if you want to preserve the previous before / after semantics.
This diagram illustrates how the pagination works:
cursor: 5
skip: 0 or undefined
โ
โ
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ 1 โโ 2 โโ 3 โโ 4 โโ 5 โโ 6 โโ 7 โโ 8 โโ 9 โโ10 โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โโโโโโโโโ
take: -2
cursor: 5
skip: 1
โ
โ
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ 1 โโ 2 โโ 3 โโ 4 โโ 5 โโ 6 โโ 7 โโ 8 โโ 9 โโ10 โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โโโโโโโโโ
take: -2
cursor: 5
skip: 2
โ
โ
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ 1 โโ 2 โโ 3 โโ 4 โโ 5 โโ 6 โโ 7 โโ 8 โโ 9 โโ10 โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โโโโโโโโโ
take: -2
cursor: 5
skip: 0 or undefined
โ
โ
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ 1 โโ 2 โโ 3 โโ 4 โโ 5 โโ 6 โโ 7 โโ 8 โโ 9 โโ10 โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โโโโโโโโโโโถ
take: 3
cursor: 5
skip: 1
โ
โ
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ 1 โโ 2 โโ 3 โโ 4 โโ 5 โโ 6 โโ 7 โโ 8 โโ 9 โโ10 โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โโโโโโโโโโโถ
take: 3
cursor: 5
skip: 2
โ
โ
โ
โผ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ 1 โโ 2 โโ 3 โโ 4 โโ 5 โโ 6 โโ 7 โโ 8 โโ 9 โโ10 โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โโโโโโโโโโโถ
take: 3
Auto restart on panic
The Query Engine now automatically restarts with an exponential backoff with jitter, if it exits for some reason, for example in the case of a panic. That helps a lot to make Prisma Client more resilient in production!
#โ2100
Introspection now recognizes @default(cuid / uuid)
If you introspect a Prisma 1 schema, the introspection now correctly recognizes cuid or uuid usage
#โ2499
Fixes and improvements
prisma
prisma-client-js
vscode
19 Dec 25, 2022
5 Nov 6, 2022
26 Nov 24, 2022
10 Aug 28, 2022
3.2k Jan 3, 2023
3 Jun 27, 2022
33 Dec 19, 2022
20 Jan 2, 2023
2 Sep 28, 2021
5 May 29, 2022
21 Jan 4, 2023
26 Dec 18, 2022
297 Dec 28, 2022
18 Nov 30, 2022
4 May 9, 2022
3 Feb 22, 2022
5 Dec 20, 2022
7 Dec 15, 2022
9 Dec 23, 2022