[Multi Schema] Same model map different schema

[danstarns]

Bug description

I am using multiSchema, and I have the following schema:

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

datasource db {
  provider = "postgresql"
  url      = ...
  schemas  = ["base", "transactional"]
}

model User {
  email String
  posts Post[]

  @@map("some_table")
  @@schema("base")
}

model Post {
  title    String
  authorId String
  author   User?  @relation(fields: [authorId], references: [id])

  @@map("some_table")
  @@schema("transactional")
}

The User model belongs to the base schema and it is mapped to the some_table tabel name.

The Post model belongs to the transactional schema and it is mapped to the some_table tabel name.

I get the error:

Error: Get DMMF: Schema parsing - Error while interacting with query-engine-node-api library
Error code: P1012
error: Error validating: The argument `references` must refer only to existing fields in the related model `User`. The following fields do not exist in the related model: id
  -->  schema.prisma:24
   | 
23 |   authorId String
24 |   author   User?  @relation(fields: [authorId], references: [id])
   | 
error: The model with database name "some_table" could not be defined because another model with this name exists: "User"
  -->  schema.prisma:21
   | 
20 | 
21 | model Post {
22 |   title    String
23 |   authorId String
24 |   author   User?  @relation(fields: [authorId], references: [id])
25 | 
26 |   @@map("some_table")
27 |   @@schema("transactional")
28 | }
   | 

How to reproduce

1. Take the given schema
2. Run npx prisma migrate dev

Expected behavior

Both models map to the same tabel name some_table however, they are in different schemas and so this should work.

Prisma information

Environment & setup

• OS: Mac OS
• Database: PostgreSQL
• Node.js version: 18.2.0

Prisma Version

dev

[tomhoule]

Can confirm that the name collision is a bug, the mapped names should be qualified with their schema while checking for mapped name collisions. In terms of implementation, HashSet<(Option<String>, String)> instead of HashSet<String>. The extra Option<String> would be the schema name, so the logic does not need to change for prisma schemas without @@schema annotations (they'll just always have None there).

[Jolg42]

Opened a PR to adapt the current test #15647

[Jolg42]

Reopening until test from #15647 is merged (currently not passing because engine is not up-to-date)

[Jolg42]

In our dev version it now errors with a different error message with #15647 (comment)

We want to fix this.