1-n many relation works implicitly without specifying the foreign key

I’m not sure we would consider this a bug but it certainly seems a bit strange that this is functional so I wanted to raise it here on GitHub. The following schema creates a correct 1-n relation in the DB without the foreign key being specified in the Prisma schema:

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

datasource db {
  provider = "postgresql"
  url      = "postgresql://nikolasburk:nikolasburk@localhost:5432/testdb1"
}

model user {
  id             String        @id @default(uuid()) @db.Uuid()
  email          String        @unique
  password       String
  createdAt      DateTime      @default(now()) @map("created_at")
  organization   organization? @relation(references: [id])
}
model organization {
  id        String   @id @default(uuid()) @db.Uuid()
  name      String
  createdAt DateTime @default(now()) @map("created_at")
  users     user[]
}

Running prisma migrate dev creates the following SQL:

-- CreateTable
CREATE TABLE "user" (
    "id" UUID NOT NULL,
    "email" TEXT NOT NULL,
    "first_name" TEXT NOT NULL,
    "last_name" TEXT,
    "password" TEXT NOT NULL,
    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "organizationId" UUID,

    PRIMARY KEY ("id")
);

-- CreateTable
CREATE TABLE "organization" (
    "id" UUID NOT NULL,
    "name" TEXT NOT NULL,
    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,

    PRIMARY KEY ("id")
);

-- CreateIndex
CREATE UNIQUE INDEX "user.email_unique" ON "user"("email");

-- AddForeignKey
ALTER TABLE "user" ADD FOREIGN KEY ("organizationId") REFERENCES "organization"("id") ON DELETE SET NULL ON UPDATE CASCADE;

My understanding is that foreign keys should be made explicit in the Prisma schema and specified via references inside the @relation attribute. If the case above should be allowed, we probably should document this approach too.

[pantharshit00]

I would also say this schema should be rejected by that validator. I have candidated this issue so that we can have a look into this in the next planning.

[do4gr]

This should be solved by us splitting the parsing and formatting step here https://github.com/prisma/prisma-engines/pull/1662