Removing `@unique` from 1:n relation scalar field not picked up by Migrate

Steps

1. With the following schema, generate a migration

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["nativeTypes"]
}

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

model Envelope {
  id            Int            @id @default(autoincrement())
  ClaimedCoupon ClaimedCoupon[]
}

model ClaimedCoupon {
  id         Int      @id @default(autoincrement())
  envelopeId Int      @unique
  Envelope   Envelope @relation(fields: [envelopeId], references: [id])
}

-- CreateTable
CREATE TABLE `Envelope` (
    `id` INTEGER NOT NULL AUTO_INCREMENT,

    PRIMARY KEY (`id`)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- CreateTable
CREATE TABLE `ClaimedCoupon` (
    `id` INTEGER NOT NULL AUTO_INCREMENT,
    `envelopeId` INTEGER NOT NULL,
UNIQUE INDEX `ClaimedCoupon.envelopeId_unique`(`envelopeId`),

    PRIMARY KEY (`id`)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- AddForeignKey
ALTER TABLE `ClaimedCoupon` ADD FOREIGN KEY (`envelopeId`) REFERENCES `Envelope`(`id`) ON DELETE CASCADE ON UPDATE CASCADE;

1. Remove @unique from field envelopeId and run prisma migrate dev. Prisma Migrate will claim the database is in sync and not drop the index.

Notes

In general, this is a bit of an edge case, because adding the uniqueness constraint, turns the 1:n relation into a 1:1 relation. Usually, developers would utilize our specific 1:1 syntax for this.

It does impact potentially developers who may be transitioning from a 1:1 to a 1:n relation. Surely if they have defined the uniqueness constraint manually (Prisma already creates such an index under the hood).

[tomhoule]

@janpio I am pretty sure this is not related to any of the relation uniqueness issues we have dealt with recently.

[tomhoule]

@twofingerrightclick There’s an issue about this: https://github.com/prisma/prisma/issues/10503 — it’s the only case where Prisma implicitly adds indexes/constraints even if they’re not in your schema, and I’d like to get rid of it, but it will be a breaking change (so it’s going to be for Prisma 4 at the earliest).