Incorrect migration creates on sql server when index deleted

Bug description

Initial prisma model contains unique keys:

model Logbook {    
  categoryId     String?         @db.UniqueIdentifier
  date           DateTime       @db.Date()
  @@unique([date, categoryId], name: "Date_Category_unique_constraint")
}

It creates such sql statement: -- CreateIndex CREATE UNIQUE NONCLUSTERED INDEX [Logbook_date_categoryId_key] ON [dbo].[Logbook]([date], [categoryId]); When I delete unique constraint from prisma’s schema model

model Logbook {    
  categoryId     String?         @db.UniqueIdentifier
  date           DateTime       @db.Date()
}

it creates migration with such statement: -- DropIndex ALTER TABLE [dbo].[Logbook] DROP CONSTRAINT [Logbook_date_categoryId_key]; Applying this migration throws an error: “Database error: ‘Logbook_date_categoryId_key’ is not a constraint.”

How to reproduce

1. Add unique keys constraint for your model
2. Apply migration
3. Delete constraint
4. Apply migration

Expected behavior

Should call DROP INDEX, not DROP CONSTRAINT;

Prisma information

model Logbook {    
  categoryId     String?         @db.UniqueIdentifier
  date           DateTime       @db.Date()
  @@unique([date, categoryId], name: "Date_Category_unique_constraint")
}

Environment & setup

• OS: Windows
• Database: Sql Server
• Node.js version: 16.15.1

Prisma Version

3.15.1

[pimeys]

I made a fix, this should work with all Prisma cases. Read the details from the PR above.

Now you should manually edit the drop to your migration for it to work. In the future, if you alter a table with @unique, we add a constraint instead of an index. This can then be dropped with DROP CONSTRAINT.

Definitely interesting how SQL Server makes a distinction here, and why you can’t drop a unique index with DROP CONSTRAINT.

[pimeys]

Ah, found it! So you must first create a table without a unique constraint, then add it and then remove it again. Now it fails.