-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Incorrect Include typings when having models called X
and XUpdate
#7518
Comments
Hey @ianmartorell Can you please try this again with the latest version ? If you can still reproduce this, please also share the schema of |
Hi @pantharshit00, I have updated Prisma to the latest version (2.25.0) and the issue persists. Since I have both a model called Here's the schema of model OrderItem {
id String @id @default(uuid())
quantity Int @default(1)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
productUpdateId String
productUpdate ProductUpdate @relation(fields: [productUpdateId], references: [id])
orderId String
order Order @relation(fields: [orderId], references: [id])
orderItemStatusId String
orderItemStatus OrderItemStatus @relation(fields: [orderItemStatusId], references: [id])
} |
Here's a repro https://github.com/ianmartorell/prisma-issue-7518 |
@janpio @pantharshit00 Any idea when this could be looked over? If it's gonna take a while, I'll dedicate some time to rework our current Prisma schema to avoid this issue. |
Next step would be for @pantharshit00 to get a confirmed reproduction, then someone from the developers would take a look and hopefully directly be able to reproduce as well, and then find a fix. Hard to say how complex that will be, before it actually happens - sorry. |
No problem, thank you for the quick reply :) |
Sorry for the late reply here. This got buried in my notifications. I can confirm the conflict and marking this as candidate. |
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 having two models called
X
andXUpdate
, the generated types forinclude
parameters ofXUpdate
are incorrect.How to reproduce
Example (only relevant fields included):
Then, when querying another model that has a relation with
ProductUpdate
:I get the following error:
Looking at the generated types, this seems to be because the
productUpdate
field inOrderItemInclude
has typeProductUpdateArgs
, which are the arguments for an update operation on aProduct
model, instead of the args without action of theProductUpdate
model.Expected behavior
The type of
OrderItemInclude.productUpdate
should be related to theProductUpdate
model, not theProduct
model. Consequently there should not be a type error in this situation.Prisma information
Relevant prisma schema provide above.
Environment & setup
Prisma Version
The text was updated successfully, but these errors were encountered: