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
Prisma 4.3.0 takes 100x more time to generate types #15109
Comments
Same here, 74 models took 631.71s.
|
holey moley that could be why my yarn install is taking so long 😱 |
Yes same here-with 4.2.1 it took under 3 seconds. 4.3.0 just took 418 seconds. |
@annibuliful may I suggest you update the title to say |
@capaj Thank you very much |
My Github Action exceed the limit now 😭 😭 😭 😭 😭 |
Hi @annibuliful, @phongkt-dev, @capaj, can you please share your schema with us? It'd be very useful for investigating this issue, thanks. |
actually I tried with my schema that is open source and there is no slowdown on that schema. It's only the confidential schema where I have the problem. |
Thank you @capaj! You can even send the schema privately to schemas@prisma.io. |
Check you inbox. |
@jkomyno This is my schema |
Just to make explicit: |
Yes I used the same as V4.2.1 |
same here-I just have
|
In #14982, we introduced generic input types and a function for determining if particular input type needs generic argument. That function traversed whole type graph starting with given types in search for field references. It did not do any caching, so if particular type was encountered multiple types in different relations, whole traversal happened each time. Fixed by replacing that helper function with a class with a built-in cache for results. Now, each type would be checked at most once. Fix #15109
Thanks for the report and schemas. We'll keep you updated as we are thinking about doing a patch release for this. |
In #14982, we introduced generic input types and a function for determining if particular input type needs generic argument. That function traversed whole type graph starting with given types in search for field references. It did not do any caching, so if particular type was encountered multiple types in different relations, whole traversal happened each time. Fixed by replacing that helper function with a class with a built-in cache for results. Now, each type would be checked at most once. Fix #15109
In #14982, we introduced generic input types and a function for determining if particular input type needs generic argument. That function traversed whole type graph starting with given types in search for field references. It did not do any caching, so if particular type was encountered multiple types in different relations, whole traversal happened each time. Fixed by replacing that helper function with a class with a built-in cache for results. Now, each type would be checked at most once. Fix #15109
In #14982, we introduced generic input types and a function for determining if particular input type needs generic argument. That function traversed whole type graph starting with given types in search for field references. It did not do any caching, so if particular type was encountered multiple types in different relations, whole traversal happened each time. Fixed by replacing that helper function with a class with a built-in cache for results. Now, each type would be checked at most once. Fix #15109
Hey everyone! |
In #14982, we introduced generic input types and a function for determining if particular input type needs generic argument. That function traversed whole type graph starting with given types in search for field references. It did not do any caching, so if particular type was encountered multiple types in different relations, whole traversal happened each time. Fixed by replacing that helper function with a class with a built-in cache for results. Now, each type would be checked at most once. Fix #15109 (cherry picked from commit 6b1a5fa)
tested today with 4.3.1, problematic schema built in 3 seconds. Nicely done! |
Thanks for the feedback!
|
Bug description
V. 4.3.0
V.4.2.1
How to reproduce
Expected behavior
Prisma information
Environment & setup
Prisma Version
The text was updated successfully, but these errors were encountered: