Issue with constraint primary key when using drizzle-kit push 2 times.
Hello! I am facing an issue where if I use
drizzle-kit push
2 times without making any changes on a schema with a table with a constraint primary key.
First push. Works as intended.
Second push. Gives an error.
Ran sql command when pushing the second time:
A reproduction can be tried cloning this repository (the problem doesn't appear in https://drizzle.run). https://github.com/PureSci/drizzle-push-issueGitHub
GitHub - PureSci/drizzle-push-issue
Contribute to PureSci/drizzle-push-issue development by creating an account on GitHub.
16 Replies
Hi 👋 I can reproduce.
The only way is to comment
push, uncomment and push again :/
Looks like the same behaviour as https://orm.drizzle.team/kit-docs/faq#how-push-and-generate-works-for-postgresql-indexes.
It only happen for composite PK
Drizzle ORM - FAQ & Troubleshooting
Drizzle ORM is a lightweight and performant TypeScript ORM with developer experience in mind.
cc @Andrii Sherman
well it also happens when you dont uncomment :Pepe_sad: (outside drizzle run)
I am running into a similar issue with migrate. The migration file looks like this
So you can see that drizzle-kit is dropping all composite PKs and then readding? It produces the following error when running drizzle-kit migrate:
Btw this just happened to me after updating to the latest version of drizzle-orm and drizzle-kit
To better understand, it happens on an existing project with existing migrations?
Can you tell me what was the version before you upgrade?
I would like to reproduce.
For push, I am not surprised.
I don’t know if it is really expected or a bug but push is mostly used for drafting the db.
I am more worried about migrate that should be non destructive if it is not intentional (like renaming things).
(Note that I am not part of the dev team, so I can be wrong 😬)
It was a project with existing migration files, yes. Before upgrade I was on drizzle-kit 0.19, now on 0.23
I hadn’t changed any names or anything in the schema except for adding that column which you can see at the bottom of the migration file I shared above.
ok I see, major bumps. There was some breaking changes between. I am searching the related changelogs
Also for reference I have never used push in this project 😊
Haha yes I am now on 0.23
I am pretty sure it is expected, at least once since https://github.com/drizzle-team/drizzle-kit-mirror/releases/tag/v0.22.0. But I need a joker ( @Andrew Sherman ). I can’t remember the exact moment, but when you don’t name the constraint, it is generated and the way it is generated has changed.
In the code you provided, it tries to delete the previous one by guessing the naming.
(users_to_scenes_user_id_scene_unique_name to rename it users_to_scenes_user_id_scene_unique_name_pk).
I see. So what is the solution here then?
@zendev ok I was able to recreate the same behaviour.
So, if you have committed your changes (to be able to revert in case something mess-up).
I guess you have done a
drizzle-kit up
like suggested?
Keep somewhere a copy of the last generated migration (the one that has been created since you upgrade).
Now you can drizzle-kit drop
and drop this last migration. We will fix the schema and generate a new one.
I am right assuming that you have primary keys defined with primaryKey()
? (third arg of pgTable
)
Maybe your code looks like :
Now it should be:
if the name
property of primaryKey
is missing, Drizzle kit try to guess it [table_name][col_name_1][col_name_2]
, following the order in columns
.
the idea is to name all your constraint (primaryKey
here) like the pattern mentioned, to prevent kit to try migrate them.
note: I am not really 100% sure, I have solved similar issues in the past but it was months ago.Amazing thank you I will try this and get back to you
👍 if it is an open source project and you are still stuck, do not hesitate to share 🫡
@Raphaël M (@rphlmr) ⚡ it worked! Thank you so much 🙏🏽
Just curious - do I now need to keep this “name” property in the schema forever?