From 766d36ff80622a036ecc1feefeed1aa5618c3468 Mon Sep 17 00:00:00 2001 From: Muhammad Ibrahim Date: Sat, 4 Oct 2025 10:44:06 +0100 Subject: [PATCH] fix: migration to properly drop unique index on friendly_name The migration was dropping the constraint but not the underlying unique index. In PostgreSQL, unique constraints and unique indexes can exist independently. This caused auto-enrollment to fail with 'unique constraint violated' errors. Added explicit DROP INDEX statement to ensure the unique index is removed, allowing duplicate friendly_name values while machine_id remains unique. --- .../20251004090459_add_machine_id_to_hosts/migration.sql | 3 +++ 1 file changed, 3 insertions(+) diff --git a/backend/prisma/migrations/20251004090459_add_machine_id_to_hosts/migration.sql b/backend/prisma/migrations/20251004090459_add_machine_id_to_hosts/migration.sql index 026a0fa..035422b 100644 --- a/backend/prisma/migrations/20251004090459_add_machine_id_to_hosts/migration.sql +++ b/backend/prisma/migrations/20251004090459_add_machine_id_to_hosts/migration.sql @@ -7,6 +7,9 @@ UPDATE "hosts" SET "machine_id" = 'migrated-' || "api_id" WHERE "machine_id" IS -- Remove the unique constraint from friendly_name ALTER TABLE "hosts" DROP CONSTRAINT IF EXISTS "hosts_friendly_name_key"; +-- Also drop the unique index if it exists (constraint and index can exist separately) +DROP INDEX IF EXISTS "hosts_friendly_name_key"; + -- Now make machine_id NOT NULL and add unique constraint ALTER TABLE "hosts" ALTER COLUMN "machine_id" SET NOT NULL; ALTER TABLE "hosts" ADD CONSTRAINT "hosts_machine_id_key" UNIQUE ("machine_id");