test(schema-engine): allow SQLite migration to be D1-compatible #4808
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
WASM Query Engine file Size
|
CodSpeed Performance ReportMerging #4808 will not alter performanceComparing Summary
|
…ing_all_referenced_columns_of_foreign_key_works" and "migrations::relations::adding_mutual_references_on_existing_tables_works"
✅ WASM query-engine performance won't change substantially (0.996x)Full benchmark reportAfter changes in 61ede41 |
This was referenced May 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR closes https://github.com/prisma/team-orm/issues/1081.
This PR allows the Prisma Schema Engine to emit Cloudflare D1-compatible migration scripts when
provider = "sqlite".In particular, the
PRAGMA foreign_key_checkstatement, which was previously only used at the end of any SQLite migration script, is now replaced withPRAGMA foreign_key_check("$TABLE"), where$TABLEis the name of the table that was altered by the migration.When multiple tables are involved in a migration, the expected diff for
prisma migrateis:PRAGMA foreign_keys=OFF; CREATE TABLE "new_Post" ( "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "title" TEXT NOT NULL, "content" TEXT, "published" BOOLEAN NOT NULL DEFAULT false, "authorId" INTEGER NOT NULL, FOREIGN KEY ("authorId") REFERENCES "User" ("id") ON DELETE RESTRICT ON UPDATE CASCADE ); INSERT INTO "new_Post" ("authorId", "content", "id", "published", "title") SELECT "authorId", "content", "id", "published", "title" FROM "Post"; DROP TABLE "Post"; ALTER TABLE "new_Post" RENAME TO "Post"; CREATE TABLE "new_User" ( "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "email" TEXT NOT NULL, "name" TEXT ); INSERT INTO "new_User" ("email", "id", "name") SELECT "email", "id", "name" FROM "User"; DROP TABLE "User"; ALTER TABLE "new_User" RENAME TO "User"; CREATE UNIQUE INDEX "User_email_key" ON "User"("email" ASC); + PRAGMA foreign_key_check("Post"); + PRAGMA foreign_key_check("User"); - PRAGMA foreign_key_check; PRAGMA foreign_keys=ON;This is necessary because
PRAGMA foreign_key_check("$TABLE");is allowed by Cloudflare D1, whereasPRAGMA foreign_key_check;isn't.Note:
foreign_key_checkPRAGMAs must be run immediately before thePRAGMA foreign_keys=ON;at the end of the migration script. Without that, the following tests would fail with a "foreign key mismatch" SQLite database error:migrations::foreign_keys::changing_all_referenced_columns_of_foreign_key_worksmigrations::relations::adding_mutual_references_on_existing_tables_works/integration