How to redo a migration on django 1.8 after using --fake

Question

Something went wrong on my migrations, I added a new datetimefield to a model then I used makemigrations and migrate.

python manage.py makemigrations
python manage.py migrate

But after this the migrate got an "table already exists error". I supposed I could fake the migrations and start over, so I did

python manage.py makemigrations --fake core

Operations to perform:
  Apply all migrations: core
Running migrations:
  Rendering model states... DONE
  Applying core.0001_initial... FAKED
  Applying core.0002_auto_20150525_1331... FAKED
  Applying core.0003_auto_20150525_1348... FAKED
  Applying core.0004_processo_data_atualizacao... FAKED

but the new migrate that I've just created was faked too (of course!).

How is the proper way to redo a migration (in this case the core.0004) after doing this?

Solution

You should first set your current state to 0003 with --fake (assuming 0003 is the last migration you really have applied):

python manage.py migrate --fake core 0003

And then proceed as usual:

python manage.py migrate core

Relevant documentation: https://docs.djangoproject.com/en/dev/ref/django-admin/#migrate

Comments

[spectras]

In south it was possible to pass a specific step you wanted to migrate to. It would then migrate forward or backwards, to just after the given step. Was that feature dropped when they merged it into Django?

[Spc_555]

@spectras no it wasn't, it's exactly the same

[Evyatar Sivan]

what if it was the first migration that I used --fake on?

[Spc_555]

@EvyatarSivan you should use zero instead of migration number, e.g. python manage.py migrate --fake core zero

[Christian Long]

See also the --fake-initial flag docs.djangoproject.com/en/1.8/topics/migrations/….

[JiminyCricket]

FYI If you use zero instead of a migration number, you will lose any data in that table

[Onengiye Richard]

Kindly note that core is the name of the app