Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
APACHE-2.0 License
Published by timsuchanek over 4 years ago
Today, we are issuing the 2.1.3
patch release.
Published by timsuchanek over 4 years ago
Today, we are issuing the 2.1.2
patch release.
Published by timsuchanek over 4 years ago
Today, we are issuing the 2.1.1
patch release.
prisma migrate
Published by timsuchanek over 4 years ago
Today, we are issuing the 2.1.0
stable release.
Next to a lot of bug fixes, this version includes a number of new features.
Json
data in Prisma ClientWhen 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 }
},
})
📚 Documentation: Working with Json
fields
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"
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.
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!
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.
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
When updating or creating a record, we now provide a new operation as a nested mutation: connectOrCreate
.
You can connect (if exists) or create (if it doesn't exist) to a related row.
📚 Documentation: Relation queries: connectOrCreate
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]"
}
}
}
}
})
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).
//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])
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 https://github.com/prisma/prisma-client-js/issues/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).
In the Prisma CLI, we are using dedicated experimental flags that can be added to any command.
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 https://github.com/prisma/prisma/issues/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).
prisma
Option::unwrap()
on a None
value"prisma init
to supply connection string to be used in datasource
generate
/validate
Environment variables loaded from
uses wrong directory separator (slashes) on Windows@prisma/debug
logs in testsdatasources
in Prisma Client constructor parametersprisma-client-js
JsonFilter
input has no fieldscreate
and update
__internal
from typesvscode
type_alias
from auto-completion studio
prisma-engines
Published by timsuchanek over 4 years ago
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 🤗.
prisma introspect
got improved so there are fewer false positives that tell users their database is Prisma 1.Published by nikolasburk over 4 years ago
🎉 Today, we are launching Prisma 2.0 for General Availability! Read the announcement to learn more.
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.
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.
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! 🙌
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!
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.
Published by timsuchanek over 4 years ago
Today, we are issuing the ninth Beta release: 2.0.0-beta.9
(short: beta.9
).
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.
prisma
prisma-client-js
vscode
prisma-engines
uniqueIndexes
to Model in DMMFdefault
for Field in DMMF Huge thanks to @Sytten for helping!
Published by timsuchanek over 4 years ago
Today, we are issuing the eighth Beta release: 2.0.0-beta.8
(short: beta.8
).
.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 rows
queryRaw
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.
prisma
npx prisma generate
issue if working directory contains spacesstring
.prisma-client-js
Huge thanks to @Sytten, @merelinguist for helping!
Published by timsuchanek over 4 years ago
Today, we are issuing the seventh Beta release: 2.0.0-beta.7
(short: beta.7
).
Prisma Client's pagination has been simplified a lot!
first
, last
, before
, after
arguments.cursor
and take
arguments.skip
argument unchanged.The take
argument replaces first
and last
.
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
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!
https://github.com/prisma/prisma/issues/2100
@default(cuid / uuid)
If you introspect a Prisma 1 schema, the introspection now correctly recognizes cuid
or uuid
usage
https://github.com/prisma/prisma/issues/2499
prisma
generate
does not work in folders with spacesfindMany
with a select
argument errors out with models with self-relations (sometimes)select
ed in queriesfindMany
fails to select
an enum list & a relation scalar at the same timeprisma-client-js
vscode
@default()
puts curcor after )
instead of inside ()
@unique @unique
prisma-engines
Huge thanks to @Sytten, @thankwsx, @zachasme for helping!
Published by timsuchanek over 4 years ago
Today, we are issuing the sixth Beta release: 2.0.0-beta.6
(short: beta.6
).
raw
queries with Prisma ClientThanks to @zachasme and @Sytten, the prisma.raw
command became more powerful in https://github.com/prisma/prisma/pull/2311. There are two changes we introduce for raw
:
sql-template-tag
helpersPrisma Client's raw
mode utilizes the sql-template-tag
library. In order to construct raw SQL queries programmatically, Prisma Client now exposes a few helper functions:
import { sql, empty, join, raw, PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
const rawQueryTemplateFromSqlTemplate = await prisma.raw(
sql`
SELECT ${join([raw('email'), raw('id'), raw('name')])}
FROM ${raw('User')}
${sql`WHERE name = ${'Alice'}`}
${empty}
`
)
Sometimes, a static template string is not enough. Then constructing a string dynamically is the right choice. For this situation, we added support for arbitrary positional parameters:
const result = await prisma.raw(
'SELECT * FROM User WHERE id = $1 OR email = $2;',
1,
'[email protected]'
)
?pgbouncer=true
parameter (forceTransactions
from the PrismaClient
is now deprecated and will be removed in an upcoming release)prisma format
prisma
introspect
success message&sslcert=server-ca.pem
in PostgreSQL connection url throw Error opening a TLS connection: One or more parameters passed to a function were not valid.
prisma format
will move it out of the modelPrisma Client
does not workprisma-client-js
forceTransactions
/ pgBouncervscode
prisma-engines
Huge thanks to @Sytten, @thankwsx, @zachasme for helping!
Published by timsuchanek over 4 years ago
Today, we are issuing the fifth Beta release: 2.0.0-beta.5
(short: beta.5
).
From now on, you don't need to build your own binaries for Alpine Linux and all musl-based distros anymore. They're shipped by default with the Prisma CLI and Prisma Client.
The new Node v14 is from now on fully supported with the Prisma CLI and Prisma Client.
You can now use the new Json
type that was introduced in the last release also in Prisma Client.
prisma
prisma-client-js
migrate
vscode
prisma-engines
Huge thanks to @Sytten for helping!
Published by timsuchanek over 4 years ago
Today, we are issuing the fourth Beta release: 2.0.0-beta.4
(short: beta.4
).
Prisma now supports working with JSON data with the new Json
type in the Prisma data model.
Here's an overview of how it works with different Prisma tools/workflows:
The prisma introspect
command maps the following column types to Json
:
JSON
and JSONB
JSON
prisma migrate
uses the following data type when creating a column for a field of type Json
:
JSONB
JSON
Fields of type Json
will be exposed as plain JavaScript objects in the Prisma Client API.
prisma format
From now on, you can run prisma format
in your project, to make your schema.prisma
pretty without the VSCode extension 💅
Prisma now supports Yarn workspaces 🎉
.prisma
folderThe generation of Prisma Client into node_modules
sometimes caused problems with package managers (e.g. Yarn) which would occasionally delete the generated code.
In order to make the generation more robust, Prisma Client is now generated into a folder called node_modules/.prisma
. Because of the leading dot in the folder name, package managers do not touch the folder any more. This results in the following folder structure:
node_modules/
↪ .prisma
↪ client
↪ schema.prisma
↪ index.js
↪ index.d.ts
↪ query-engine-darwin
↪ @prisma/client (imports the generated code from `.prisma`)
Note that the generated Prisma Client code in .prisma
is now imported into @prisma/client
which means there is no change for how you import and use Prisma Client in your code! You can still import Prisma Client as before with:
import { PrismaClient } from '@prisma/client'
The prisma studio --experimental
command now accepts a --browser
option to let you choose your preferred browser for Prisma Studio, e.g.:
prisma studio --browser "Google Chrome" --experimental
Here's an overview of the browser names you can use per platform (note that double quotes are required when the browser name contains space and the right capitalization is required too):
OS | Browser | Argument for --browser
|
---|---|---|
Mac OS | Chrome | "Google Chrome" |
Firefox | "Firefox" |
|
Firefox (Developer) | "Firefox Developer Edition" |
|
Safari | "Safari" |
|
Windows | Chrome | "Google Chrome" |
Firefox | "Firefox" |
|
Firefox (Developer) | "Firefox Developer Edition" |
|
Brave | "Brave" |
|
Linux | Chrome | "google-chrome" |
Firefox | "firefox" |
|
Firefox (Developer) | "firefox-developer-edition" |
|
Brave | "brave" |
prisma
RUST_BACKTRACE=full
for a verbose backtrace.introspect
fails on SQLiteprisma-client-js
null
for a nullable relation results in errornull
migrate
vscode
alpha
version of extensionHuge thanks to @Sytten for helping!
Published by timsuchanek over 4 years ago
Today, we are issuing the third Beta release: 2.0.0-beta.3 (short: beta.3).
prisma2
command is now deprecated in favor of prisma
prisma
references
must refer to a unique criteria in the related model pages_language
. But it is referencing the following fields that are not a unique criteria: page_id"MA==
@relation
annotation's field
attribute should not be able to accept scalar listsprisma introspect --print
?prisma2
executablegenerate
does not work in folders with spacesprisma-client-js
migrate
--preview
is ignored when doing prisma migrate down --preview --experimental
vscode
Published by nikolasburk over 4 years ago
Today, we are issuing the second Beta release: 2.0.0-beta.2
(short: beta.2
).
We want to give a huge shoutout to @Sytten who helped us fix some issues in the Rust codebase 🎊
count
queries in Prisma ClientIn previous versions of Prisma Client, it was not possible to provide any filter arguments when using .count
. With this release, you can provide the same filter arguments from findMany
:
const numberOfUsersCalledBob = await prisma.user.count({ where: { name: 'Bob' }})
With this release, we were able to fix a lot of nasty bugs like some schema validation issues in VS Code (#1989 and #1970) as well as a Prisma Migrate bug with 1-n self-relations.
prisma
.env
file is used - Closes #1155version
commandprisma2 generate --watch
exits when no models are defined in schema.prismaTeams
uses the scalar fields tmID. The arity of those fields must be the same. The relation field is required but the scalar fields are optional.prisma2 generate --watch
exits when no models are defined in schema.prisma.env
file is usedprisma-client-js
create
prisma-engines
migrate
Published by nikolasburk over 4 years ago
We are extremely excited to launch the first official Beta of Prisma 2.0 today! 🎉 Along with this release, we have also published a new website and an updated Prisma 2.0 documentation. This makes Prisma 2.0 the default for developers who are getting started with Prisma.
If you have been using Prisma Migrate before to create your models and their relations, the new relation syntax can seem a bit counterintuitive at first. Here's a quick overview of the most important things to consider when upgrading.
Note that this only covers one-to-one and one-to-many relations. Prisma's implicit many-to-many relations are adjusted by manually adding the @relation
attribute with a single field reference to both sides of the relation (most often this looks as follows: @relation(references: [id])
).
Consider this sample schema from preview025
:
model User {
id Int @id @default(autoincrement())
profile Profile?
posts Post[]
}
model Profile {
id Int @id @default(autoincrement())
user User // backed up by a foreign key called `user` in the DB
}
model Post {
id Int @id @default(autoincrement())
author User // backed up by a foreign key called `author` in the DB
}
CREATE TABLE "User" (
id integer PRIMARY KEY,
name text NOT NULL DEFAULT ''::text
);
CREATE TABLE "Profile" (
bio text NOT NULL DEFAULT ''::text,
id integer PRIMARY KEY,
user integer NOT NULL,
FOREIGN KEY ("user") REFERENCES "User"(id)
);
CREATE TABLE "Post" (
id integer PRIMARY KEY,
title text NOT NULL
author integer NOT NULL,
FOREIGN KEY ("author") REFERENCES "User"(id)
);
Note that in this case, the foreign keys in the underlying database are located on the Profile
and Post
tables. The User
table does not have any foreign keys (which means the profile
and posts
relation fields on the User
model are virtually maintained by Prisma).
The new syntax requires you to make the foreign key explicit in the Prisma schema (so you need to add another field in addition to the already existing relation field). This new field is your relation scalar field and directly represents the foreign key in the underlying database.
Assume you're now upgrading to 2.0.0-beta.1
:
npm install @prisma/[email protected]
npm install @prisma/[email protected] --save-dev
Without touching the database, one way to adjust your Prisma schema to adhere to the new syntax would be as follows:
model User {
id Int @id @default(autoincrement())
profile Profile?
}
model Profile {
id Int @id @default(autoincrement())
user User @relation(fields: [userId], references: [id])
+ userId Int @map("user") // relation scalar field (used in the `@relation` attribute above)
}
model Post {
id Int @id @default(autoincrement())
author User @relation(fields: [authorId], references: [id])
+ authorId Int @map("author") // relation scalar field (used in the `@relation` attribute above)
}
In this code, you introduced the userId
and authorId
fields on Profile
and Post
. These fields are your relation scalar fields and represent the foreign key in your database. But because the current foreign keys in the database are called user
and author
and therefore don't map directly to the model fields, you need to annotate the fields with @map
to "map" them to a differently named database column.
You can then re-generate Prisma Client. Note that the prisma2
command has been renamed to prisma
in 2.0.0-beta.1
, so you need to invoke the generate
command as follows:
npx prisma generate
Note that the new relation scalar field is currently read-only in the generated Prisma Client API. To modify the connections in youe database, you can keep using Prisma Client's nested write queries.
With this release the Preview period for Prisma 2.0 ends. This means that releases will not be tagged preview
any more, but with beta
. Today's release is called: 2.0.0-beta.1
.
Since its initial release, the main repository for Prisma 2.0 has been called prisma2
.
Because Prisma 2.0 is now the default for developers getting started with Prisma, the Prisma repositories have been renamed as follows:
prisma/prisma2
repository has been renamed to prisma/prisma
prisma/prisma
repository has been renamed to prisma/prisma1
prisma2
CLIDuring the Preview period, the CLI for Prisma 2.0 was invoked using the prisma2
command. With Prisma 2.0 being the default for new developers getting started with Prisma, the command is changed to just prisma
. The exising prisma
command of Prisma 1 is renamed to prisma1
.
Also note that the installation of the npm packages changes:
Prisma version | Old CLI command | New CLI command | Old npm package name | New npm package name |
---|---|---|---|---|
2.0 | prisma2 |
prisma |
prisma2 |
@prisma/cli |
1.X | prisma |
prisma1 |
prisma |
prisma1 |
The Beta release introduces a new relation syntax which makes the @relation
attribute required in each relation in the Prisma schema. Note that it often is enough to only declare the attribute only on the side of the relation (the side that stores the foreign key in the underlying database).
Additionally, for one-to-one and one-to-many relations, you need add a relation scalar field to the model which is used in the @relation
attribute. This relation scalar field directly maps to the foreign key in the underlying database. Note that the foreign key is read-only in the Prisma Client API, to modify a relation you can keep using nested write queries as before.
Here's an overview for how relations need to be updated.
During the Preview period, a 1-1-relation could be defined as follows:
model User {
id Int @id @default(autoincrement())
profile Profile
}
model Profile {
id Int @id @default(autoincrement())
user User
}
With the new Beta, you now must determine which side should store the foreign key. You can do so by adding the @relation
attribute with its corresponding relation scalar field to the model:
model User {
id Int @id @default(autoincrement())
profile Profile
}
model Profile {
id Int @id @default(autoincrement())
+ user User @relation(fields: [userId], references: [id])
+ userId Int // relation scalar field (used in the `@relation` attribute above)
}
This Prisma schema is represented as follows in SQL (the foreign key is stored on Profile
):
CREATE TABLE "User" (
id SERIAL PRIMARY KEY
);
CREATE TABLE "Profile" (
id SERIAL PRIMARY KEY,
"userId" INTEGER NOT NULL UNIQUE,
FOREIGN KEY ("userId") REFERENCES "User"(id)
);
During the Preview period, a 1-n-relation could be defined as follows:
model User {
id Int @id @default(autoincrement())
posts Post[]
}
model Post {
id Int @id @default(autoincrement())
author User
}
With the new Beta, you now must add the @relation
attribute and its corresponding relation scalar field to the non-list field of the relation:
model User {
id Int @id @default(autoincrement())
posts Post[]
}
model Post {
id Int @id @default(autoincrement())
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
}
This Prisma schema is represented as follows in SQL:
CREATE TABLE "User" (
id SERIAL PRIMARY KEY
);
CREATE TABLE "Post" (
id SERIAL PRIMARY KEY,
"authorId" integer NOT NULL,
FOREIGN KEY ("authorId") REFERENCES "User"(id)
);
During the Preview period, a m-n-relation could be defined as follows:
model Post {
id Int @id @default(autoincrement())
categories Category[]
}
model Category {
id Int @id @default(autoincrement())
posts Post[]
}
With the new Beta, you now must add the @relation
attribute to both sides of the relation:
model Post {
id Int @id @default(autoincrement())
+ categories Category[] @relation(references: [id])
}
model Category {
id Int @id @default(autoincrement())
+ posts Post[] @relation(references: [id])
}
Prisma will maintain the relation with the following relation table:
CREATE TABLE "Category" (
id SERIAL PRIMARY KEY
);
CREATE TABLE "Post" (
id SERIAL PRIMARY KEY
);
-- Relation table + indexes -------------------------------------------------------
CREATE TABLE "_CategoryToPost" (
"A" integer NOT NULL REFERENCES "Category"(id),
"B" integer NOT NULL REFERENCES "Post"(id)
);
CREATE UNIQUE INDEX "_CategoryToPost_AB_unique" ON "_CategoryToPost"("A" int4_ops,"B" int4_ops);
CREATE INDEX "_CategoryToPost_B_index" ON "_CategoryToPost"("B" int4_ops);
The changes in the relation syntax were needed to enable more complex relation configurations, e.g. when using multi-field IDs.
Note that we aim to simplify the current syntax in the future again ("take one step backward, to be able to move two steps forward").
prisma2
npm package is deprecatedThe prisma2
npm package is now deprecated, the Prisma 2.0 CLI can now be installed via the @prisma/cli
npm package, e.g.:
npm @prisma/cli --save-dev
npx prisma
To prevent confusions during installation, it now outputs the following when you try to install it:
┌─────────────────────────────────────────────────────────────┐
│ │
│ The package prisma2 has been renamed to @prisma/cli. │
│ │
│ Please uninstall prisma2 from your project or globally. │
│ Then install @prisma/cli to continue using Prisma 2.0: │
│ │
│ # Uninstall old CLI │
│ npm uninstall prisma2 │
│ │
│ # Install new CLI │
│ npm install @prisma/cli --save-dev │
│ │
│ # Invoke via npx │
│ npx prisma --help │
│ │
│ Learn more here: https://pris.ly/preview025 │
│ │
└─────────────────────────────────────────────────────────────┘
Published by nikolasburk over 4 years ago
Today, we are issuing the twenty-fifth Preview release: 2.0.0-preview025
(short: preview025
).
prisma2
npm packageWith 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.
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
# 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
prisma2 --version
output changederrorFormat
in the PrismaClient
constructor now is colorless
prisma2
datasource
block fail with Error: Schema parsing error: Unexpected token. Expected one of: End of block ("}"), alphanumeric identifier
error: Argument 'value' is missing in attribute '@default'.
Error occurred during query validation & transformation
:PANIC: Could not parse stored DateTime string: 2009-01-01 00:00:00: ParseError(Invalid)
on findMany()thread 'main' panicked at 'Expected ID field ... to be present on the model'
@default
doesnt work for enumprisma-client-js
pretty
to colorless
Error parsing GraphQL query: query parse error: Parse error at 4:3 Unexpected
}[Punctuator]Expected
Name from findMany({})
after introspectionFloat
sometimes results on sightly different value written to Postgresundefined
from findMany({})
after introspectionprisma-engines
SELECT 1
before every queryIN
queries into smaller batchesdbGenerated()
for Default valuesmigrate
Published by nikolasburk over 4 years ago
Today, we are issuing the twenty-fourth Preview release: 2.0.0-preview024
(short: preview024
).
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.
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.
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 ''
);
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")
);
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")
);
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")
);
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.
prisma2
@default
include type information@prisma/sdk
version in lockstep with prisma2
introspect
for SQLite returns id
as String
when it should be Int
DEBUG
env var)migrate
prisma-client-js
prisma-engines
cargo test
commandint
as Integer on SqlitePublished by nikolasburk over 4 years ago
Today, we are issuing the twenty-third Preview release: 2.0.0-preview023
(short: preview023
).
This release contains breaking changes, be sure to read the notes below before upgrading!
Because Prisma now supports composite unique constraints, the before
and after
API for cursor-pagination (which is based on unique fields) also changes. The cursor is now wrapped in an object which might have multiple fields.
Assume you have this Prisma model:
model Post {
id Int @default(autoincrement())
title String @unique
content String?
}
Before
const cursor = 42
const posts = await prisma.post.findMany({
after: cursor
})
After
const cursor = 42
const posts = await prisma.post.findMany({
after: { id: cursor }
})
enabled
property in datasource
blocksThe enabled
property was removed from the datasource
blocks.
In this issue, we're lifting a major limitation of Prisma which always required every model to have exactly one primary key constraint. In the Prisma schema, this primary key was represented using the @id
attribute.
With this release, you can now have tables:
Read below for more information on each of these new features. Lifting these limitations was a major effort, please be sure to report any bugs or other issues you encounter using these new features!
In previous Prisma versions, there was a hard requirement that every model in your Prisma schema needed to have a single @id
field (which maps to a primary key constraint in the underlying database). This requirement is now lifted and your models don't need primary key constraints any more to be compatible with Prisma 2 (they do need at least one unique constraint though).
For example, this data model is now valid:
model Post {
title String @unique
content String?
published Boolean @default(false)
author User?
}
model User {
email String @unique
name String?
posts Post[]
}
As of this release, Prisma supports composite IDs (which map to multi-column primary key constraints in the underlying database). Composite IDs are defined on a "model-level" using the @@id
attribute. Here's an example:
model User {
firstName String
lastName String
email String
@@id([firstName, lastName])
}
This also impacts the Prisma Client API and how you're querying for single records, e.g. in findOne
, update
or delete
queries where you need to identify a record by its primary key (or another unique field). These queries take the following type as input:
export type UserWhereUniqueInput = {
firstName_lastName?: FirstNameLastNameCompoundUniqueInput | null
}
export type FirstNameLastNameCompoundUniqueInput = {
firstName: string
lastName: string
}
This means, in order to query for a User
record, you need to provide both firstName
and lastName
fields wrapped inside a firstName_lastName
object:
const user = await prisma.user.findOne({
where: {
firstName_lastName: {
firstName: "Jane",
lastName: "Doe"
}
}
})
As of this release, Prisma also supports composite unique constraints (which map to multi-column unique constraints in the underlying database). Composite unique constraints are defined on a "model-level" using the @@unique
attribute.
Note: Primary key and unique constraints are very similar but have some differences on the database-level. You can learn more about the differences here.
Here's an example:
model User {
firstName String
lastName String
email String
@@unique([firstName, lastName])
}
This also impacts the Prisma Client API and how you're querying for single records, e.g. in findOne
, update
or delete
queries where you need to identify a record by its primary key (or another unique field). These queries take the following type as input:
export type UserWhereUniqueInput = {
firstName_lastName?: FirstNameLastNameCompoundUniqueInput | null
}
export type FirstNameLastNameCompoundUniqueInput = {
firstName: string
lastName: string
}
This means, in order to query for a User
record, you need to provide both firstName
and lastName
fields wrapped inside a firstName_lastName
object:
const user = await prisma.user.findOne({
where: {
firstName_lastName: {
firstName: "Jane",
lastName: "Doe"
}
}
})
Prisma's introspection now reconized DEFAULT
constraints that are defined on a column. These constraints are represented in the generated Prisma schema using the @default
attribute.
When building a GraphQL server with Prisma Client, it wasn't easy to avoid the n+1 problem with nested queries. This release of Prisma Client optimizes the execution of GraphQL nested queries by batching requests against the database.
prisma2
generate --watch
brokenOption::unwrap()
on a None
value.raw
template literal API with parameters #1583Option::unwrap()
on a None
valueError: P4001 The introspected database was empty: undefined
url or file if sqlite should be displayed instead of undefined(left == right)
.raw
template literal API with parametersgenerate
shows "Downloading ..." every time when a custom binaryTarget is specifiedgenerate
prisma-client-js
.raw
template literal API with parametersJSON.parse(dmmfString)
fails on prisma schema with docsnative
, Prisma Client automatically resolves rhel-openssl-1.0.x
"datamodel.mdl
) and client name (Photon JS
) in graphic in README need to be updatedprisma-engines
@map
into account when migrating enum valuesPublished by nikolasburk over 4 years ago
Today, we are issuing the twenty-second Preview release: 2.0.0-preview022
(short: preview022
).
This release contains breaking changes, be sure to read the notes below before upgrading!
prisma.raw(sql)
(read the API docs)prisma2 init
now uses environment variables and creates a .env
fileThe following change is only breaking if you're using introspection and are currently using Prisma Client API calls that are referencing a virtual back-relation field. Read on to learn more.
When introspecting a table with a foreign key, Prisma automatically creates a "virtual back-relation" field on the respective Prisma model. Consider the following SQL schema:
CREATE TABLE User (
user_id SERIAL PRIMARY KEY NOT NULL,
name VARCHAR(256),
);
CREATE TABLE Post (
post_id SERIAL PRIMARY KEY NOT NULL,
title VARCHAR(256) NOT NULL,
author_id INTEGER,
FOREIGN KEY (author_id) REFERENCES User(user_id)
);
In previous Prisma 2 preview versions, the resulting Prisma data model after introspection used to be:
model User {
user_id Int @id @default(autoincrement())
posts Post[] // before `preview022`
}
model Post {
post_id Int @id @default(autoincrement())
title String
author User?
}
Notice the posts
field which has been added by Prisma. This field does not exist as a column on the database-level, but is a "virtual back-relation" field in the Prisma schema.
With preview022
, the pluralization of the virtual back-relation field has been removed. The new introspection result would be:
model User {
user_id Int @id @default(autoincrement())
post Post[] // after `preview022`
}
model Post {
post_id Int @id @default(autoincrement())
title String
author User?
}
.env
file changedAs explained in this issue, the path to the default .env
file is changed in this Preview version. Before, the Prisma CLI automatically loaded the environment variables from a .env
file in the current working directory. This now changes and it only loads them from the directory that contains the schema.prisma
file.
Enums in the Prisma schema are now mapped to enums in the underlying database (previously they were represented as strings). This means enum support for SQLite is completely removed since SQLite doesn't support enums.
prisma2
warning In order to use "@prisma/client", please install prisma2. You can install it with "npm add -D prisma2"
is printed even when prisma2 is installed.raw
API@prisma/client@x is not compatible with prisma2@y. Their versions need to be equal.
, generates anywaygetDatabaseDescription
if error consent screen didn't have confirmation.env
file next to schema.prisma
@@id
refers to original field name instead of @map
-ped oneintrospect
: "Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed"generate
: "Error: Schema parsing --- thread 'main' has overflowed its stack"id
is a String in the schema but an Integer in SQLite.--schema
?)introspect
command, backup behavior⠋ Introspecting MySQL schema with 1 tables.
during introspectionUpsert
causes random self-referencing 1:1 relations to breakprisma-client-js
nextTick
- based batchingundefined
and Errorgenerate
tells me to install wrong Prisma Client packagenull
in ENUM filtersmigrate
--help
does not need --experimental
for main migrate
, does for migrate save
prisma-engines
Published by nikolasburk over 4 years ago
Today, we are issuing the twenty-first Preview release: 2.0.0-preview021
(short: preview021
).
This release contains breaking changes, be sure to read the notes below before upgrading!
⚠️ If you're using Prisma together with GraphQL Nexus and nexus-prisma, check out the additional release notes of nexus-prisma
: https://github.com/prisma-labs/nexus-prisma/releases/tag/0.9.0
The property on the PrismaClient
that exposes CRUD operations per model used to be lowercased and pluralized, the pluralization of that property is now removed.
For example, for a model User
you'd access a CRUD operation via the generated prisma.users
property, as in prisma.users.findMany()
. As of preview021
, the pluralization has been removed and the property is called after the model (but lowercased), so it would now be prisma.user.findMany()
.
Here are few more examples showing how the calls to your PrismaClient
instance must be adjusted:
Prisma schema
model User {
id Int @id @default(autoincrement())
name String
}
Generated Prisma Client API
const prisma = new PrismaClient()
// CRUD operations are exposed via:
- // prisma.users
+ // prisma.user
// findMany
- const users = await prisma.users.findMany()
+ const users = await prisma.user.findMany()
// findOne
- const user = await prisma.users.findOne({ where: { id: 1 }})
+ const user = await prisma.user.findOne({ where: { id: 1 }})
// create
- const user = await prisma.users.create({ data: { name: "Alice" }})
+ const user = await prisma.user.create({ data: { name: "Alice" }})
// and so on ...
Besides many small fixes, Prisma Client JS now uses JSDoc to bring API documentation to your fingertips as you write code in your editor:
prisma2
generate --help
message to Generate artifacts (e.g. Prisma Client)
Prisma is a modern DB toolkit to query, migrate and model your database
prisma2 migrate docs
undefined
in prisma2 init --help
outputprisma introspect
prisma2 init
fails in Yarn Workspacesprisma-client-js
findOne
without argspg-bouncer
set
for scalarList is not provided or it is set to []
postinstall
script of this package fails if using env var in my schemamigrate
prisma-engine
@default(autoincrement())
@map
for relation fields that use compound references