Unique/Index keeps getting recreated
See original GitHub issueBug description
Following the schema defined below, prisma generates the following initial migration:
-- CreateTable
CREATE TABLE "authors" (
"id" SERIAL NOT NULL,
"name" TEXT NOT NULL,
"image_id" INTEGER,
"created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updated_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT "authors_pkey" PRIMARY KEY ("id")
);
CREATE TABLE "documents" (
"id" SERIAL NOT NULL,
"created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updated_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT "documents_pkey" PRIMARY KEY ("id")
);
-- CreateIndex
CREATE UNIQUE INDEX "authors_name_key" ON "authors"("name");
-- CreateIndex
CREATE INDEX "documents_updated_at_idx" ON "documents"("updated_at" DESC);
So far so good.
Now I run npx prisma migrate dev --create-only --name something
and make NO changes to the Author or Document model in the schema:
/*
Warnings:
- A unique constraint covering the columns `[name]` on the table `authors` will be added. If there are existing duplicate values, this will fail.
*/
-- DropIndex
DROP INDEX "authors_name_key";
-- DropIndex
DROP INDEX "documents_updated_at_idx";
-- CreateIndex
CREATE UNIQUE INDEX "authors_name_key" ON "authors"("name");
-- CreateIndex
CREATE INDEX "documents_updated_at_idx" ON "documents"("updated_at" DESC);
And it does this for all other similar models too in the schema! Which will obviously fail, since the index can’t just be deleted on everything.
This happens again at every migration.
How to reproduce
See description.
Expected behavior
No response
Prisma information
This is just an excerpt…
datasource db {
provider = "postgresql"
url = env("DB_URL")
}
generator client {
provider = "prisma-client-js"
previewFeatures = ["extendedIndexes", "filterJson"]
}
model Author {
id Int @id @default(autoincrement())
name String @unique
image Asset? @relation(fields: [imageId], references: [id])
imageId Int? @map("image_id")
contents AuthorsToContent[]
createdAt DateTime @default(now()) @map("created_at")
updatedAt DateTime @default(now()) @updatedAt @map("updated_at")
@@map("authors")
}
model Document {
id Int @id @default(autoincrement())
createdAt DateTime @default(now()) @map("created_at")
updatedAt DateTime @default(now()) @updatedAt @map("updated_at")
@@index([updatedAt(sort: Desc)])
@@map("documents")
}
Environment & setup
- OS: Ubuntu 20.04
- Database: PostgreSQL
- Node.js version: 17.3.1
Prisma Version
prisma : 3.9.1
@prisma/client : 3.9.1
Current platform : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine : migration-engine-cli bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary : prisma-fmt bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash : bcc2ff906db47790ee902e7bbc76d7ffb1893009
Studio : 0.457.0
Preview Features : extendedIndexes, filterJson
Issue Analytics
- State:
- Created 2 years ago
- Reactions:13
- Comments:17 (4 by maintainers)
Top Results From Across the Web
How do I rebuild a UNIQUE index if there are duplicate values?
The simplest way to determine whether this has occured is to attempt to rebuild the index normally. There are two approaches:.
Read more >database - Is it possible to alter a MySQL unique index to non ...
No, in MySQL it is not possible to change the definition of an index without dropping it and recreating it. There is no...
Read more >Postgres: Recreating Indexes supporting Unique, Foreign Key ...
Also, if the index you are recreating is a unique index, you can add the keyword UNIQUE to the CREATE INDEX command.
Read more >Option to set a unique index unusable prior to mass data inserts
The result of this behaviour is frequently that such indexes are dropped before and recreated after the data integration - and that's not...
Read more >Getting "Record already exists" error on non-unique index
Getting "Record already exists" error on non-unique index. ... Dropping and recreating the index may work, but is not guaranteed when the ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks for reporting this everyone and sorry it took us so long to fix this!
I’ve back worked around this by running a function that removes these lines and then updates the database migration tables by recalculating the sha256 hashes.