-
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
Help us improve the Re-Introspection Workflow by sharing your Prisma Schema and SQL schemas 🙏 #2711
Comments
Thank you, this is an awesome initiative. My SQL is huge, I will happily give it to you, but for simplicity, I will also sum up what I need to do now and what I would like to do, but due to the size am unable. I am now just testing the framework with nexus-prisma, thus I only use 5 tables of this monstrosity (namely: My database is due to its age and an old program (in Delphi) still in our native language. To make it worst a lot of columns are not very vel named, as 3 characters shortcuts were seen as the best approach. What I do after every introspection:
What I would like to do
dumb.sql-- Server version 8.0.18 schema.prismagenerator client { provider = "prisma-client-js" } |
I don't think Prisma 1 set up my enums as a column property in MySQL, so I had to add those back after an introspection. Now, I think if I introspected, it might find them. I also switched from MySQL 5.7 to 8 (the main impetus for upgrading the Prisma 2, the timing of the G.A. was just fortuitous), so I'm not sure where that enum feature evolved exactly. |
@theRocket I am happy to investigate this in more detail and possibly give you some pointers (we have an upgrade tool for P1->P2 for example) - best create an issue and link to it here (or @ mention me). |
Thanks, @janpio. I did use the prisma-upgrade tool, but I think I may have discovered it after already running one introspection. That tool has good instructions for the correct order of operation, but I think that first introspect dropped the enums since 5.7 didn't have them in schema. I have all this in branches and containers, so I could reproduce it. |
Sweet, just post the issue link here then after creating it and we can take a deeper look. |
I think I ran into this issue as well with IDs. Basically after a second re-introspection of a postgres database, this happened to all my IDs:
this to my timestamps:
which I don't think is what I want... |
I think it's related to this one (and the one below) but it's be really nice if introspection could be smart enough to leave any @id annotations with the same column name untouched if there's such additional annotations, I do see that it says "Note that you'll have to re-add the attribute after each introspection because introspection removes it (as the previous version of the Prisma schema is overwritten)!" |
If you could send us your SQL and Prisma schemas to schemas@prisma.io that would be great - then we will add your schema to our CI system that will make sure we get better on this over time @louisrli 👍 |
EDIT: I am using the For Also, I believe it was mentioned in another issue, but I need to manually set |
|
@harryttd Can you please share the SQL and the database (Postgres or MySQL?) that you are using? |
This comment has been minimized.
This comment has been minimized.
All your Re-Introspection problems fixed with what we released in #2711 (comment)? If not, please open a new issue so we can discuss the problem and find a solution. |
Big update over at #2829 (comment) |
Hey everyone 👋
We want to remove one of the remaining big pain points of Introspection:
If you manually adjusted your data model after introspection (to rename fields or models, or add default IDs for example) these changes are currently lost once you introspect again ("re-introspect", for example, because your database was changed manually or migrated by another tool).
It would, therefore, be a tremendous help for us if you could share your projects where you encountered this problem! The information we need is the following:
Please submit your database schemas and Prisma Schemas to schemas@prisma.io.
Also, note that we're happily signing NDAs if your schemas and data models need to be treated confidently! If you like Prisma and want to see it succeed, please consider sharing your schema and data model or talking to your boss if that's needed to be able to share your information! 🙂
Thanks for helping us making Prisma better 🙌
The text was updated successfully, but these errors were encountered: