-
-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
Comments
I think migration files should not be changed/deleted by aerich at all, unless developer explicitly wants it (like Django's "merge migrations" command) |
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 |
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 |
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 |
Use case:
Change model
Run
areich migrate
Migration file X has been created
Change model again (don't upgrade db)
Run
aerich migrate
againMigration 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
The text was updated successfully, but these errors were encountered: