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

[alexshurik]

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]

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]

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]

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]

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