Introspection is changing field casing
See original GitHub issueI think naming rules can be improved significantly, as many people already mentioned above.
I encountered this problem today while migrating to the newest version (2.14.0
at the moment) of prisma migrate
. Earlier in my project, I’ve created a database with legacy prisma migrate
cli.
So, for example, I have the types Employee
and Degree
with many-to-many relation. And I have all names in camelCase in those types. In the old version, prisma migrate
has created a reference table called _DegreeToEmployee
. So, when I ran the new introspection - it renamed the existing field on Degree
like so:
- employees Employee[] @relation(references: [id])
+ Employee Employee[]
New introspection certainly needs to properly address these kinda cases in the future. Main suggestions:
- when migrating from older versions of
prisma
- preserve original field names for all kinds of relations (1-1, 1-many, many-many); - casing should be inferred or set manually, via command parameter, for example.
P.S.: Btw, I didn’t notice it at first and wasted a lot of hours, trying to understand, why my code broke, totally my fault tho. Needless to say, it was quite annoying to manually review generated diff, because my schema is quite large.
_Originally posted by @ivankhm in https://github.com/prisma/prisma/issues/3659#issuecomment-759812738_
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
Hi! Sorry for the delay, I didn’t check my email for notifications 😦
I’m not sure, if you need the hole schema, because this problem occurred with only 4 models, but just in case, here it is. My database was first populated with tables back in beta-2 via experimental prisma migrate, if that helps. Right now I’m using
prisma@2.14.0
. I runnpx prisma introspect
on my “old” schema:Schema before introspection
And here is after
npx prisma introspect
, the problem is with modelsSchedule
,ScheduleTag
,Employee
andDegree
, witch got field naming changes. It’s strange because other many-to-many relations are perfectly fine.Schema after
Just in case, here is an example of tables in actual db:
Screenshots
I am going to close this as its been 2 months now and there is no activity here.
Please reply if you want us to take another look.