BUG: Postgres migration script generates a few syntax errors
Context: I was running migrations with drizzle-kit's migration function from
node-postgres , and kept getting a lot of errors.
I had to make the following changes to the SQL script:
1. Add double quotes around table, index, and other field names
2. Array fields with default values just never generated the right code. So I had to manually add the default value in.
Screenshots show the full picture
25 Replies
Thanks
Will patch release this fix today and ping you
So, quotes were fixed in
[email protected]. You can check it
Could you please show how ts schema looks like for array column? Simple row should be enough. Want to know how default was defined(if it was). It will help me to spot an issue faster
Right after I'll fix default for array - I'll release patch fix to latest
@Andrii Sherman
Ok, great! Thanks for the details
Working on it
thanks ! @Andrii Sherman !
FYI @Andrii Sherman I checked out the latest version and got a migration file generated that didn't have double quotes.
See screenshot attached
yep
plus ran
yarn install to update @Andrii Sherman
any updates @Andrii Sherman?yeah, still didn't have a chance to look at it
will ping right after I'll check it and fix
perfect thanks!
@rushil1o1 [email protected] should have all fixes with escape characters. Just try to regenerate migrations
Defaults for arrays still in progress
thank you so much! will check it out
Tested it and it works perfectly. Unfortunately, we can't use it yet - 0.22.0 -> 0.23.0 had some breaking changes for us syntactically.
Spread operator on select is deprecated (?)
Getting the following error:
Also, pgEnum.enumValues changed from TValues to string[] which is throwing inference errors for us. š¦
@Andrii Sherman
@bloberenober
The pgEnum issue will be fixed, but for spreading you can get the columns from
getTableConfig() and operate on themThanks @bloberenober , @Andrii Sherman
That helps --- We'll probably upgrade once the enum issue is fixed. The migration issue is a non-blocker for us and we can just continue to manually annotate migrations with double quotes
FYI: here's our enum workaround - https://discord.com/channels/1043890932593987624/1090155866789007380
this is maybe why I ended with what I shared in your previous post š
. works fine like that but Iām thinking of removing db enums š¤
DB enums are not very convenient in the first place, which is why we introduced the "text enums" as an alternative
That's what I missed in Prisma: literals. Now it changes everything If nobody manually add records in DB :p
Well, you can always add check constraints
@rushil1o1 the pgEnum issue was fixed in
0.23.6thank you so much! @bloberenober - will check it out soon!
all good - everything works! -- tested the new migration as well; @Andrii Sherman @bloberenober
in hindsight - we should have kept our DB models // attributes in snake case - (since SQL defaults to that if you don't use quotes) lol
it shouldn't be an issue since we escape all names, was just a bug in the query generation
nice!