I've made a migration that added a new table and want to revert it and delete the migration, without creating a new migration.
How do I do it? Is there a command to revert last migration and then I can simply delete the migration file?
You can revert by migrating to the previous migration.
For example, if your last two migrations are:
0010_previous_migration
0011_migration_to_revert
Then you would do:
./manage.py migrate my_app 0010_previous_migration
You don't actually need to use the full migration name, the number is enough, i.e.
./manage.py migrate my_app 0010
You can then delete migration 0011_migration_to_revert
.
If you're using Django 1.8+, you can show the names of all the migrations with
./manage.py showmigrations my_app
To reverse all migrations for an app, you can run:
./manage.py migrate my_app zero
The answer by Alasdair covers the basics
./manage.py showmigrations
migrate
using the app name and the migration nameBut it should be pointed out that not all migrations can be reversed. This happens if Django doesn't have a rule to do the reversal. For most changes that you automatically made migrations by ./manage.py makemigrations
, the reversal will be possible. However, custom scripts will need to have both a forward and reverse written, as described in the example here:
https://docs.djangoproject.com/en/1.9/ref/migration-operations/
If you had a RunPython
operation, then maybe you just want to back out the migration without writing a logically rigorous reversal script. The following quick hack to the example from the docs (above link) allows this, leaving the database in the same state that it was after the migration was applied, even after reversing it.
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import migrations, models
def forwards_func(apps, schema_editor):
# We get the model from the versioned app registry;
# if we directly import it, it'll be the wrong version
Country = apps.get_model("myapp", "Country")
db_alias = schema_editor.connection.alias
Country.objects.using(db_alias).bulk_create([
Country(name="USA", code="us"),
Country(name="France", code="fr"),
])
class Migration(migrations.Migration):
dependencies = []
operations = [
migrations.RunPython(forwards_func, lambda apps, schema_editor: None),
]
This works for Django 1.8, 1.9
Update: A better way of writing this would be to replace lambda apps, schema_editor: None
with migrations.RunPython.noop
in the snippet above. These are both functionally the same thing. (credit to the comments)
Don't delete the migration file until after the reversion. I made this mistake and without the migration file, the database didn't know what things to remove.
python manage.py showmigrations
python manage.py migrate {app name from show migrations} {00##_migration file.py}
If you want to revert all migrations, use zero
as the name of the migration:
python manage.py migrate app_name_here zero
Delete the migration file. Once the desired migration is in your models...
python manage.py makemigrations
python manage.py migrate
Here is my solution, since the above solution do not really cover the use-case, when you use RunPython
.
You can access the table via the ORM with
from django.db.migrations.recorder import MigrationRecorder
>>> MigrationRecorder.Migration.objects.all()
>>> MigrationRecorder.Migration.objects.latest('id')
Out[5]: <Migration: Migration 0050_auto_20170603_1814 for model>
>>> MigrationRecorder.Migration.objects.latest('id').delete()
Out[4]: (1, {u'migrations.Migration': 1})
So you can query the tables and delete those entries that are relevant for you. This way you can modify in detail. With RynPython
migrations you also need to take care of the data that was added/changed/removed. The above example only displays, how you access the table via Djang ORM.
To revert a migration:
python manage.py migrate <APP_NAME> <MIGRATION_NUMBER_PREFIX>
MIGRATION_NUMBER_PREFIX
is the number prefix of the migration you want to revert to, for instance 0001
to go to 0001_initial.py
migration. then you can delete that migration.
You can use
zero
as your migration number to revert all migrations of an app.
The other thing that you can do is delete the table created manually.
Along with that, you will have to delete that particular migration file. Also, you will have to delete that particular entry in the django-migrations table(probably the last one in your case) which correlates to that particular migration.
I did this in 1.9.1 (to delete the last or latest migration created):
rm <appname>/migrations/<migration #>*
example: rm myapp/migrations/0011*
logged into database and ran this SQL (postgres in this example)
delete from django_migrations where name like '0011%';
I was then able to create new migrations that started with the migration number that I had just deleted (in this case, 11).
If you are facing trouble while reverting back the migration, and somehow have messed it, you can perform fake
migrations.
./manage.py migrate <name> --ignore-ghost-migrations --merge --fake
For django version < 1.7 this will create entry in south_migrationhistory
table, you need to delete that entry.
Now you'll be able to revert back the migration easily.
PS: I was stuck for a lot of time and performing fake migration and then reverting back helped me out.
This answer is for similar cases if the top answer by Alasdair does not help. (E.g. if the unwanted migration is created soon again with every new migration or if it is in a bigger migration that can not be reverted or the table has been removed manually.)
...delete the migration, without creating a new migration?
TL;DR: You can delete a few last reverted (confused) migrations and make a new one after fixing models. You can also use other methods to configure it to not create a table by migrate command. The last migration must be created so that it match the current models.
Cases why anyone do not want to create a table for a Model that must exist:
A) No such table should exist in no database on no machine and no conditions
class Meta: abstract = True
B) The table is created rarely, by something else or manually in a special way.
class Meta: managed = False
C) The table is used only on some machine (e.g. in development).
class Meta: managed = some_switch
.D) The project uses multiple databases in settings.DATABASES
allow_migrate
in order to differentiate the databases where the table should be created and where not.The migration is created in all cases A), B), C), D) with Django 1.9+ (and only in cases B, C, D with Django 1.8), but applied to the database only in appropriate cases or maybe never if required so. Migrations have been necessary for running tests since Django 1.8. The complete relevant current state is recorded by migrations even for models with managed=False in Django 1.9+ to be possible to create a ForeignKey between managed/unmanaged models or to can make the model managed=True later. (This question has been written at the time of Django 1.8. Everything here should be valid for versions between 1.8 to the current 2.2.)
If the last migration is (are) not easily revertible then it is possible to cautiously (after database backup) do a fake revert ./manage.py migrate --fake my_app 0010_previous_migration
, delete the table manually.
If necessary, create a fixed migration from the fixed model and apply it without changing the database structure ./manage.py migrate --fake my_app 0011_fixed_migration
.
there is a good library to use its called djagno-nomad, although not directly related to the question asked, thought of sharing this,
scenario: most of the time when switching to project, we feel like it should revert our changes that we did on this current branch, that's what exactly this library does, checkout below