-
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
include
not working on models ending with ...Update
with unique compound index
#18902
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
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
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
This issue is now fixed and the fix will be published as a part of |
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
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:
Use
findUniqueOrThrow
to query theuser_update
table using the unique compound indexid_tenantId
: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:If we rename the model so it doesn't end with
Update
, everything works fine: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:
Environment & setup
Prisma Version
The text was updated successfully, but these errors were encountered: