'rails db:migrate reverts newer migrations if an old one is run for the first time
I have an app with Rails 7.0.0 and I've noticed some behaviour with db:migrate that I think it didn't happen with previous versions.
Whenever a migration is added to master from another branch and newer migrations already exists in master, when I run db:migrate the newer migrations are reverted before the newly added migration is run. For example, if I have these output in rails db:migrate:status:
down 20220325080850 Add new fields
up 20220330064816 Create new table
When running rails db:migrate, it will just revert "Create new table". When run again, it'll migrate both. Sample output (times are 0.000s because I left the methods empty for testing purposes):
> bin/rails db:migrate
== 20220330064816 CreateNewTable: reverting ===============================
...
== 20220330064816 CreateNewTable: reverted (0.0000s) ======================
> bin/rails db:migrate
== 20220325080850 AddNewFields: migrating ===================================
...
== 20220325080850 AddNewFields: migrated (0.0000s) ==========================
== 20220330064816 CreateNewTable: migrating ===============================
...
== 20220330064816 CreateNewTable: migrated (0.0000s) ======================
I guess this is a safety mechanisn. Is it new? I haven't found any documentation for it. Can it be disabled? Because it can be pretty dangerous. I'd prefer the task to just run the missing migrations without reverting any new migration.
Solution 1:[1]
It looks like this was a bug. It's resolved in version 7.0.2.3 and with that it works as expected (running only the missing migrations)
edit: this is the issue with the bug https://github.com/rails/rails/issues/43833 it happened only in multi-db apps (the app I had the issue with is multi-db).
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 |
