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

The generated updateArgs have no update attribute #19967

Closed
larryro opened this issue Jun 26, 2023 · 3 comments · Fixed by #20184
Closed

The generated updateArgs have no update attribute #19967

larryro opened this issue Jun 26, 2023 · 3 comments · Fixed by #20184
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. team/client Issue for team Client. tech/typescript Issue for tech TypeScript. topic: type-clash
Milestone

Comments

@larryro
Copy link

larryro commented Jun 26, 2023

Bug description

When we define two models, one is xxx and the other is xxxUpdate, and xxxUpdate is placed before xxx, we cannot update xxx with Prisma Client.

image
image
image

How to reproduce

  1. Define two models with no corresponding relationships, such as PostUpdate and Post and make sure PostUpdate is ahead of Post.
model PostUpdate {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  content   String?
}

  1. Use PrismaClient to update Post.
await prisma.post.update({
    where: { id: 1 },
    data: { published: true },
  });

  1. We can see that where and data do not exist as parameter properties
    image
    image

Expected behavior

We should be able to use the update method to update posts normally.

Prisma information

generator client {
  provider = "prisma-client-js"
}

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

model PostUpdate {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  content   String?
}
await prisma.post.update({
    where: { id: 1 },
    data: { content: "test" },
  });

Environment & setup

  • OS: Windows
  • Database:MySQL, SQLite
  • Node.js version: v18.14.2

Prisma Version

Environment variables loaded from .env
prisma                  : 4.16.1
@prisma/client          : 4.16.1
Current platform        : windows
Query Engine (Node-API) : libquery-engine b20ead4d3ab9e78ac112966e242ded703f4a052c (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine        : migration-engine-cli b20ead4d3ab9e78ac112966e242ded703f4a052c (at node_modules\@prisma\engines\migration-engine-windows.exe)
Format Wasm             : @prisma/prisma-fmt-wasm 4.16.0-66.b20ead4d3ab9e78ac112966e242ded703f4a052c
Default Engines Hash    : b20ead4d3ab9e78ac112966e242ded703f4a052c
Studio                  : 0.484.0
@larryro larryro added the kind/bug A reported bug. label Jun 26, 2023
@FJ001
Copy link

FJ001 commented Jun 28, 2023

Is it a system breaking bug?
Is xxxUpdate is being placed before xxx necessary in some cases?

@jkomyno jkomyno added tech/typescript Issue for tech TypeScript. team/client Issue for team Client. bug/1-unconfirmed Bug should have enough information for reproduction, but confirmation has not happened yet. labels Jun 29, 2023
@Jolg42
Copy link
Member

Jolg42 commented Jun 29, 2023

I didn't try to reproduce this yet, but I think this is a type clash
Related issues

@larryro Could you try renaming your PostUpdate model?

If you want, you can only change the Prisma Client name and keep the table name in the database the same using @@map like:

generator client {
  provider = "prisma-client-js"
}

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

model PostSomething {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
	@@map("PostUpdate")
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  content   String?
}

Let me know if that helped, we're aware of some type clashes, and we have ideas on how to fix them, I hope it happens "soon" but I can't say when.

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 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
@Jolg42 Jolg42 added this to the 5.1.0 milestone 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. tech/typescript Issue for tech TypeScript. topic: type-clash
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants