drop tables
Is there a way to do a migration to drop tables? Other ORMs like Sequelize and Prisma have a concept of up & down migrations, but Drizzle doesn't. Is there a Drizzle way to do a "down" migration?
15 Replies
So looks like drizzle kit does indeed create migrations to drop tables when you remove them from the schema file. but i'd still like to know if you can do incremental up/down migrations?
we don't have support for down migrations
so far any down migration is a new migration with dropping something
no incremental migrations? like doing 1 or 2 in a step?
are there are plans to support down migration? I'd say it is a must for everyday dev cycle. thanks
Why do you need it when developing new feature?
We will have down migrations, but thinking about a situation of a rollback while production deploy
Not sure about a use case for development
bug in migration - rollback, fix migration, up again; without the possibility to rollback it's manual labour
If you are using Postgres and there is a bug in migration - it will be rollbacked automatically because all migration scripts are covered in transactions
So no need to down migration
If you are using databases without DDL transaction support, then this flow will still not be useful.
For example, the up migration will break on the 3rd statement out of 5. How would you write a down script so that it can be executed successfully? Alternatively, what if there is a bug in both the down and up migrations?
ok I meant a different case - prototyping, made wrong assumptions about tables, I would like to correct and push only the final version - like a squashed commit - I would not like to push 7 migrations showing my messy development process.
Okay, I see. In this case, it may seem like a more appropriate approach:
1. You write an up+down migration.
2. If you don't like something, you run the down migration.
3. Modify the up and down migrations.
4. Repeat all steps until you are satisfied with your migration.
The problem here is that you need to manage two scripts just for the development flow. For such cases, we have a command called
push. We support it in MySQL and SQLite, and soon we will have support for Postgres as well. The great thing about it is that it's really useful for prototyping your schema. You can apply any changes to your local database right away without needing to rewrite the up and down migration scripts. Once you finish prototyping, you can generate the up script just once.
In this case, you don't need separate up and down scripts. As I mentioned before, I still see the down script as great only for rollbacks during production deployments. We have spent a lot of time using it in various production projects and found that we hardly ever used the down scripts, except for a few deployments where we wanted to ensure smoothness. But those were only 1% of all the deployments we had.
Here's another good workflow that has worked well for us before having push command
Each time you work on a new feature:
1. Get the development database to your local db, with or without data (your choice).
2. Generate as many migration files as you need until you are ready with your feature.
3. Remove all those migrations using 'drizzle-kit drop' from the project files.
4. Generate a single migration.
5. Dump the development database one more time.
6. Run the final migration and test your feature. After that, you are ready to deploy.
However, all of these steps can be omitted with drizzle-kit push
For references you can check
1. https://orm.drizzle.team/kit-docs/overview#prototyping-with-db-push
2. https://orm.drizzle.team/kit-docs/commands#prototype--push
3. https://orm.drizzle.team/kit-docs/config-reference
And an article example for SQLite:
https://driz.li/sqlite-pushok thanks for the explanation @Andrew Sherman
@Andrew Sherman what is the timeline to support push for postgresql?
I think I will be ready with v1 this week
do you have current status of this? Sorry for pinging but we are going full speed on Drizzle and "down" on migrations, exactly for production rollback is something we are also exploring with drizzle
i'd be curious about this too
I can't say when down migrations will be in drizzle. I'll try to go through backlog and make it in a higher priority
And what about tests? In the case when I want to roll back all migrations before each test and migrate again