Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

include not working on models ending with ...Update with unique compound index #18902

Closed
dfillion opened this issue Apr 24, 2023 · 1 comment · Fixed by #20184
Closed

include not working on models ending with ...Update with unique compound index #18902

dfillion opened this issue Apr 24, 2023 · 1 comment · Fixed by #20184
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/client Issue for team Client. topic: type-clash
Milestone

Comments

@dfillion
Copy link

Bug description

include typing does not work on model with a name ending by ...Update when querying with a unique compound index.

How to reproduce

Use the following Prisma schema:

model User {
  id         String       @id @default(uuid())
  userUpdate UserUpdate[]

  @@map("user")
}

model UserUpdate {
  id       String @id @default(uuid())
  tenantId String @map("tenant_id")
  user     User   @relation(fields: [userId], references: [id])
  userId   String

  @@unique([id, tenantId])
  @@map("user_update")
}

Use findUniqueOrThrow to query the user_update table using the unique compound index id_tenantId:

  const { user } = await prismaClient.userUpdate.findUniqueOrThrow({
    where: { id_tenantId: { id: 'user_id', tenantId: 'tenant_id' } },
    include: { user: true }
  });

We have the following Typescript error: TS2339: Property 'user' does not exist on type 'UserUpdate'.

If we use the unique index id, everything works fine:

  const { user } = await prismaClient.userUpdate.findUniqueOrThrow({
    where: { id: 'user_id' },
    include: { user: true }
  });

If we rename the model so it doesn't end with Update, everything works fine:

model User {
  id         String           @id @default(uuid())
  userUpdate UserUpdateTest[]

  @@map("user")
}

model UserUpdateTest {
  id       String @id @default(uuid())
  tenantId String @map("tenant_id")
  user     User   @relation(fields: [userId], references: [id])
  userId   String

  @@unique([id, tenantId])
  @@map("user_update")
}
  const { user } = await prismaClient.userUpdateTest.findUniqueOrThrow({
    where: { id_tenantId: { id: 'user_id', tenantId: 'tenant_id' } },
    include: { user: true }
  });

Expected behavior

When using include on a model with a name ending with ...Update and querying with a compound unique index, generated type includes the relation.

Prisma information

Same information linked in bug description:

model User {
  id         String       @id @default(uuid())
  userUpdate UserUpdate[]

  @@map("user")
}

model UserUpdate {
  id       String @id @default(uuid())
  tenantId String @map("tenant_id")
  user     User   @relation(fields: [userId], references: [id])
  userId   String

  @@unique([id, tenantId])
  @@map("user_update")
}
  const { user } = await prismaClient.userUpdate.findUniqueOrThrow({
    where: { id_tenantId: { id: 'user_id', tenantId: 'tenant_id' } },
    include: { user: true }
  });

Environment & setup

  • OS: macOS
  • Database: PostgreSQL
  • Node.js version: v18.15.0

Prisma Version

"@prisma/client": "4.13.0",
"prisma": "4.13.0",
@dfillion dfillion added the kind/bug A reported bug. label Apr 24, 2023
@jkomyno jkomyno added team/client Issue for team Client. bug/1-unconfirmed Bug should have enough information for reproduction, but confirmation has not happened yet. topic: type-clash labels Apr 24, 2023
SevInf added a commit that referenced this issue Jul 12, 2023
In some cases, generated types for one of the models will clash with
generated types for another. In that case, we would generate duplicate
type.
This PR fixes this: approach is very different to namespaces proposal I
shared earlier. Turns out, most of the conflicts are solved by just
renaming default args types from `ModelArgs` to `ModelDefaultArgs`.
Deperecated alias for an old name would still be created if it does not
conflict.
Somewhat different case is `Payload` type. First, they are created at
top level of the file, rather then in `Prisma` namespace. @millsp and I
agreed that thouse types are not public, so it is safe to move them to
namespace and rename them. So, `UserPayload` would now become
`Prisma.$UserPayload`. This allows to both use `UserPayload` as a model
name as well as use `Batch` as a model name (we have built-in
`BatchPayload` type that is unrelated to aforementioned `Payload`
types).

Fix #19967
Fix #18902
Fix #16940
Fix #9568
Fix #7518
SevInf added a commit that referenced this issue Jul 12, 2023
In some cases, generated types for one of the models will clash with
generated types for another. In that case, we would generate duplicate
type.
This PR fixes this: approach is very different to namespaces proposal I
shared earlier. Turns out, most of the conflicts are solved by just
renaming default args types from `ModelArgs` to `ModelDefaultArgs`.
Deperecated alias for an old name would still be created if it does not
conflict.
Somewhat different case is `Payload` type. First, they are created at
top level of the file, rather then in `Prisma` namespace. @millsp and I
agreed that thouse types are not public, so it is safe to move them to
namespace and rename them. So, `UserPayload` would now become
`Prisma.$UserPayload`. This allows to both use `UserPayload` as a model
name as well as use `Batch` as a model name (we have built-in
`BatchPayload` type that is unrelated to aforementioned `Payload`
types).

Fix #19967
Fix #18902
Fix #16940
Fix #9568
Fix #7518
SevInf added a commit that referenced this issue Jul 18, 2023
In some cases, generated types for one of the models will clash with
generated types for another. In that case, we would generate duplicate
type.
This PR fixes this: approach is very different to namespaces proposal I
shared earlier. Turns out, most of the conflicts are solved by just
renaming default args types from `ModelArgs` to `ModelDefaultArgs`.
Deperecated alias for an old name would still be created if it does not
conflict.
Somewhat different case is `Payload` type. First, they are created at
top level of the file, rather then in `Prisma` namespace. @millsp and I
agreed that thouse types are not public, so it is safe to move them to
namespace and rename them. So, `UserPayload` would now become
`Prisma.$UserPayload`. This allows to both use `UserPayload` as a model
name as well as use `Batch` as a model name (we have built-in
`BatchPayload` type that is unrelated to aforementioned `Payload`
types).

Fix #19967
Fix #18902
Fix #16940
Fix #9568
Fix #7518
SevInf added a commit that referenced this issue Jul 18, 2023
In some cases, generated types for one of the models will clash with
generated types for another. In that case, we would generate duplicate
type.
This PR fixes this: approach is very different to namespaces proposal I
shared earlier. Turns out, most of the conflicts are solved by just
renaming default args types from `ModelArgs` to `ModelDefaultArgs`.
Deperecated alias for an old name would still be created if it does not
conflict.
Somewhat different case is `Payload` type. First, they are created at
top level of the file, rather then in `Prisma` namespace. @millsp and I
agreed that thouse types are not public, so it is safe to move them to
namespace and rename them. So, `UserPayload` would now become
`Prisma.$UserPayload`. This allows to both use `UserPayload` as a model
name as well as use `Batch` as a model name (we have built-in
`BatchPayload` type that is unrelated to aforementioned `Payload`
types).

Fix #19967
Fix #18902
Fix #16940
Fix #9568
Fix #7518
@Jolg42 Jolg42 added this to the 5.1.0 milestone Jul 18, 2023
@Jolg42 Jolg42 added bug/2-confirmed Bug has been reproduced and confirmed. and removed bug/1-unconfirmed Bug should have enough information for reproduction, but confirmation has not happened yet. labels Jul 18, 2023
@SevInf
Copy link
Contributor

SevInf commented Jul 18, 2023

This issue is now fixed and the fix will be published as a part of 5.1 release. If you'd like to verify fix earlier, you can use dev snapshot 5.1.0-dev.24. We don't recommend using it in production, but it should be enough to verify the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/client Issue for team Client. topic: type-clash
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants