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
Comments
Is it a system breaking bug? |
I didn't try to reproduce this yet, but I think this is a type clash
@larryro Could you try renaming your If you want, you can only change the Prisma Client name and keep the table name in the database the same using 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. |
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
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
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
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
This issue is now fixed and the fix will be published as a part of |
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.
How to reproduce
Expected behavior
We should be able to use the update method to update posts normally.
Prisma information
Environment & setup
Prisma Version
The text was updated successfully, but these errors were encountered: