-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Smooth upgrade path from Prisma 1 to Prisma 2.0 #1937
Comments
I want to post an update in this issue with some information about the things we are currently working on and some broader context to explain what the friction points during the upgrade process are. ExamplePrisma 1 data modelAssume you have this Prisma 1 datamodel: type User {
id: ID! @id
email: String! @unique
name: String
posts: [Post!]!
profile: Profile
}
type Post {
id: ID! @id
createdAt: DateTime! @createdAt
updatedAt: DateTime! @updatedAt
published: Boolean! @default(value: false)
title: String!
content: String
author: User!
categories: [Category!]!
}
type Profile {
id: ID! @id
bio: String
user: User! @relation(link: INLINE)
}
type Category {
id: ID! @id
name: String!
posts: [Post!]!
} Generated SQL in Prisma 1When deploying this with CREATE TABLE default$default."User" (
id character varying(25) PRIMARY KEY,
email text NOT NULL,
name text
);
CREATE UNIQUE INDEX "User_pkey" ON default$default."User"(id text_ops);
CREATE UNIQUE INDEX "default$default.User.email._UNIQUE" ON default$default."User"(email text_ops);
CREATE TABLE default$default."Post" (
id character varying(25) PRIMARY KEY,
"createdAt" timestamp(3) without time zone NOT NULL,
"updatedAt" timestamp(3) without time zone NOT NULL,
published boolean NOT NULL,
title text NOT NULL,
content text,
author character varying(25) REFERENCES default$default."User"(id) ON DELETE SET NULL
);
CREATE UNIQUE INDEX "Post_pkey" ON default$default."Post"(id text_ops);
CREATE TABLE default$default."Profile" (
id character varying(25) PRIMARY KEY,
bio text,
user character varying(25) REFERENCES default$default."User"(id) ON DELETE SET NULL
);
CREATE UNIQUE INDEX "Profile_pkey" ON default$default."Profile"(id text_ops);
CREATE TABLE default$default."Category" (
id character varying(25) PRIMARY KEY,
name text NOT NULL
);
CREATE UNIQUE INDEX "Category_pkey" ON default$default."Category"(id text_ops);
CREATE TABLE default$default."_CategoryToPost" (
"A" character varying(25) NOT NULL REFERENCES default$default."Category"(id) ON DELETE CASCADE,
"B" character varying(25) NOT NULL REFERENCES default$default."Post"(id) ON DELETE CASCADE
);
CREATE UNIQUE INDEX "_CategoryToPost_AB_unique" ON default$default."_CategoryToPost"("A" text_ops,"B" text_ops);
CREATE INDEX "_CategoryToPost_B" ON default$default."_CategoryToPost"("B" text_ops); Note that this data model has three relations:
Prisma 2.0 schema after introspectionNow you can run Prisma's introspection against your database with the following command:
For the above Prisma 1 datamodel, this results in the following Prisma 2.0 schema (note that the models and fields have been reorded to match the initial order of the Prisma 1 datamodel): model User {
id String @id
email String @unique
name String?
Post Post[]
Profile Profile[]
}
model Post {
id String @id
createdAt DateTime
updatedAt DateTime
published Boolean
title String
content String?
author String?
User User? @relation(fields: [author], references: [id])
Category Category[] @relation(references: [id])
}
model Profile {
id String @id
bio String?
user String?
User User? @relation(fields: [user], references: [id])
}
model Category {
id String @id
name String
Post Post[] @relation(references: [id])
} As you might notice, the Prisma schema is missing or has adjusted some information from the Prisma 1 datamodel:
Also note that that with Prisma 2.0, you alway must explicitly specify Fixing the Prisma 2.0 schemaAs pointed out above, the Prisma 2.0 schema that was generated from introspection has changed and even misses a lot of information from the previous Prisma 1 datamodel. The main reason for this is that in Prisma 1, most of these features have been implemented by Prisma and did not actually manifest in the database. For example, Because much of the information from the Prisma 1 datamodel does not manifest in the database schema, it can't be recognized by Prisma's introspection (which is the reason why it doesn't appear in the new Prisma schema).
You generally have two ways to resolve many of the resulting issues:
It has previusly been mentioned that we're building additional tooling that helps with the upgrade process. These tools will help you resolve the named issues automatically and will save lots of manual work. |
We also just updated the upgrade guide that was previously in this repo to cover the migration path using introspection more extensively, you can find it here. |
The migration guide currently details how to migrate from a Take a Prisma 1 model that looks like this: type Profile {
id: ID! @id
user: User @relation("UserProfiles")
}
type User {
id: ID! @id
profiles: [Profile!] @relation(name: "UserProfiles", link: TABLE)
} In this case, there is no column in user User @relation("UserProfiles", fields: [userId], references: [id])
userId String @map("User") Removing the User from Profile works, but then I can’t access a User from a Profile, only a Profile from a User. This won't work either: model User {
id Int @default(autoincrement()) @id
profiles Profile[]
}
model Profile {
id Int @default(autoincrement()) @id
user User @relation(fields: [user_id], references: [id])
user_id Int
} Prisma 2 will complain |
@nikolasburk thanks for the update, we will wait for the migrations docs. |
Hey everyone, thanks a lot for staying patient 🙏 I want to share another quick update on the state of the upgrade path to Prisma 2.0. We've just published a new docs page that has a lot of helpful information regarding the upgrade process. Most importantly, it points out all relevant schema incompatibilies and different workarounds that can be applied. For most of the workarounds, you'll actually be able to use the Prisma schema upgrade CLI tool that we're also working on.
As next steps, we will start working on more detailed migration guides for upgrading GraphQL APIs with |
Hey folks 🙌 here comes another update regarding the upgrade process to Prisma 2.0! First version of an upgrade guide for
|
Aaaand another quick update: There's another preliminary upgrade guide from |
Reminder to everyone, please share your upgrade scenario in our new feedback repo 🙏 |
Hi everyone 🙌 here comes another quick update: The guides for upgrading Note that the upgrade CLI is still in the works. As a general best practice for the upgrade process, you should always ensure to have proper backups of production-data and ideally run the upgrade in development and staging environments first. Also, a general reminder to everyone to please share your upgrade scenario in our new feedback repo 🙏 |
Hey Prisma friends 🙌 we just published the guide to upgrade from the "old" to the "new" Nexus. I'd love to get feedback for these guides! If any of you is planning to upgrade any time soon, feel free to ping me! I'd love to jump on a call with you and learn more about your upgrade scenario and discuss whether the current guides cover it enough! 🙂 As usual, my general reminder to everyone to please share your upgrade scenario in our new feedback repo 🙏 |
I'm closing this issue since we created the Upgrade CLI as well as a bunch of upgrade guides which help developers to smoothly upgrade from Prisma 1 to Prisma 2. If there are still open questions, you can post them in the upgrade feedback repo. |
We're planning to have a smooth upgrade path for existing Prisma 1 users.
The plan is to have:
nexus-prisma
prisma-binding
to Nexusprisma-binding
to SDL-firstThe text was updated successfully, but these errors were encountered: