Aerich migrate command deletes migrations with the same version (I propose always increment version of a migration file, don't delete the old ones)

tortoise / aerich

A database migrations tool for TortoiseORM, ready to production.

https://github.com/tortoise/aerich

Apache License 2.0

808 stars 91 forks source link

Aerich migrate command deletes migrations with the same version (I propose always increment version of a migration file, don't delete the old ones) #245

Open alexshurik opened 2 years ago

alexshurik commented 2 years ago

Use case:

Change model
Run areich migrate
Migration file X has been created
Change model again (don't upgrade db)
Run aerich migrate again
Migration file X has been deleted, new migration file created instead

Why I think it's dangerous This behavior can lead to problems.

Example:

Two backenders work on one project
Backender 1 creates migrations migration 1 on model 1
Backender 1 sends his changes to production
Production applies migration migration 1
Backender 2 pulls code from github
Backender 2 doesn't upgrade his local db
Backender 2 makes changes on model1
Aerich deletes migration 1 file and creates new file instead
Migration file that was applied on production has been changed

What do you think?

Version: aerich==0.6.3

alexshurik commented 2 years ago

I think migration files should not be changed/deleted by aerich at all, unless developer explicitly wants it (like Django's "merge migrations" command)

liminspace commented 2 years ago

I agree. If it's possible, it shouldn't delete and just extend migration commands in an extra file. In another case it should show an error message that non-migrated files are going to be deleted and replaced with a new one and to allow doing that you have to use some parameter like --force

mo-rijndael commented 1 year ago

Have same problem, but Aerich not just merged two migrations in same file — it generates corrupted result!

DROP INDEX "idx_bot_user_id_78ebae";
ALTER TABLE "bot" ADD "auth_data" JSONB;
ALTER TABLE "bot" DROP COLUMN "key";
ALTER TABLE "bot" DROP COLUMN "sign_key";
ALTER TABLE "bot" ADD CONSTRAINT "fk_bot_user_9f66f650" FOREIGN KEY ("user_id") REFERENCES "user" ("id") ON DELETE CASCADE;"""

Notice constraints names — they have random suffix, and this migration will fail to apply at all

Not sure, should I create a separate issue for this or not, because if Aerich stop merging migrations, this problem disappears too

UPD: okay, I tried to generate it as separate migrations, and this bug is unrelated, sorry

mo-rijndael commented 1 year ago

Also, +1 reason for not merging: migrations could be modified manually. For example, to migrate data between complex schema changes, which can't be guessed automatically