From 4347f19e947a7531fc7d4edd50d3bc6dc75db32f Mon Sep 17 00:00:00 2001 From: Adam Shiervani Date: Fri, 6 Nov 2026 13:54:50 +0100 Subject: [PATCH] Make Device.id the primary key Device had only unique indexes, so logical replication (a database move with live migration) rejects every UPDATE and DELETE on it. The migration reuses the existing unique index on id as the primary key: no table rewrite and no scan, since the column is already NOT NULL. Code that runs on the old Prisma client works with the migrated table. --- .../20261106140000_device_primary_key/migration.sql | 4 ++++ prisma/schema.prisma | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 prisma/migrations/20261106140000_device_primary_key/migration.sql diff --git a/prisma/migrations/20261106140000_device_primary_key/migration.sql b/prisma/migrations/20261106140000_device_primary_key/migration.sql new file mode 100644 index 0000000..779e3d4 --- /dev/null +++ b/prisma/migrations/20261106140000_device_primary_key/migration.sql @@ -0,0 +1,4 @@ +-- Device.id becomes the primary key. The existing unique index on "id" is +-- reused, so Postgres renames it to "Device_pkey" without rebuilding it. The +-- column is already NOT NULL, so no table scan is needed. +ALTER TABLE "Device" ADD CONSTRAINT "Device_pkey" PRIMARY KEY USING INDEX "Device_id_key"; diff --git a/prisma/schema.prisma b/prisma/schema.prisma index 493b1cc..e87b36d 100644 --- a/prisma/schema.prisma +++ b/prisma/schema.prisma @@ -23,7 +23,7 @@ model User { } model Device { - id String @unique + id String @id lastSeen DateTime? @db.Timestamp(6) name String? user User @relation(fields: [userId], references: [id])