Prisma thinks named relation - @ralation (name:..) - is a field with unique constraint

[ysahnpark]

Bug description

Prisma considers field with named relation @relation(name: "MyRelation", fields:[]...) as field with unique constraint, even though I have not defined themas unique.

Hence when I try to insert a new record that references same FK, it fails with unique constraint violation.

Note: I am using the named relation to disambiguate multiple fields referencing same table.

For example the following model:

model Code {
  ...
  facilityEmissionSourceActivitySource OrgFacilityEmissionSource? @relation("FacilityEmissionSource_activitySource")
}

model OrgFacilityEmissionSource {
  ...
  activitySource    Code?    @relation(name: "FacilityEmissionSource_activitySource", fields: [activitySourceUid], references: [uid])
  activitySourceUid String?  @db.VarChar(40)
}

Generates the following code:

-- CreateIndex
CREATE UNIQUE INDEX "OrgFacilityEmissionSource_activitySourceUid_key" ON "OrgFacilityEmissionSource"("activitySourceUid");

and

// index.d.ts
export type OrgFacilityEmissionSourceWhereUniqueInput = {
    uid?: string
    unitUid?: string
    activitySourceUid?: string
  }

How to reproduce

1. Create models in schema.prisma with named relations, e.g.

model Code {
  ...
  facilityEmissionSourceActivitySource OrgFacilityEmissionSource? @relation("FacilityEmissionSource_activitySource")
}

model OrgFacilityEmissionSource {
  ...
  activitySource    Code?    @relation(name: "FacilityEmissionSource_activitySource", fields: [activitySourceUid], references: [uid])
  activitySourceUid String?  @db.VarChar(40)
}

2. run npm prisma generate
3. check the generated migration file for CREATE UNIQUE INDEX
4. check the generated index.d.ts for OrgFacilityEmissionSourceWhereUniqueInput that includes activitySourceUid as one of the fields for unique input.

Expected behavior

Unless explicitly declared as @unique, prima generate should not generate code that handles those fields as unique.

Prisma information

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

generator client {
  provider = "prisma-client-js"
  // Below allows embedding logic within transaction. 
  // See https://www.prisma.io/docs/concepts/components/prisma-client/transactions
  previewFeatures = ["interactiveTransactions"]
}

Environment & setup

• OS: MacOS
• Database: PostgreSQL
• Node.js version: v16.14.0

Prisma Version

prisma                  : 3.10.0
@prisma/client          : 3.10.0
Current platform        : darwin
Query Engine (Node-API) : libquery-engine 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : 73e60b76d394f8d37d8ebd1f8918c79029f0db86
Studio                  : 0.458.0
Preview Features        : interactiveTransactions

[tomhoule]

Hi @ysahnpark , this is an instance of #10503 — Prisma Migrate will create a unique in that place, and we rely on that unique constraint to enforce that the relation is one-to-one, and not one-to-many.

We want to change that behaviour so it becomes closer to your intuition. I am personally pushing for this to be included in the next major release of Prisma and hope it will make it. Thanks for reporting the issue! let's track progress on this in #10503