Upgrading throws errors on migration because tables already exist

[kelseyq]

Caused by #136
I recently upgraded from 1.5.0 to 1.6.0 and running migrate throws the error
django.db.utils.ProgrammingError: relation "axes_accessattempt" already exists
because it's trying to run the newly added migrations files even though the tables have already been created. This is especially hard to deal with on apps deployed to Heroku

[kelseyq]

It looks like this is due to 1.8 adding the --fake-initial flag, which used to be applied automatically?
https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdoption-migrate--fake-initial
Not sure how to fix

[camilonova]

You can:

1. Drop axes tables and let the migration creates them again
2. Run ./manage.py migrate axes --fake

[kelseyq]

Proposed solution 1 both loses data that is potentially useful for forensics and disrupts functionality (resets cooloff time, etc.) The correct flag to add when migrating is --fake-initial, not -fake (I believe this would skip the change in 1.6.0 to add indexes.) #146 adds that to the changelog, so other users are aware.

[abhigyantiwari]

@camilonova What if we already have lots of data in the same table?

[aleksihakli]

@abhigyantiwari This issue was closed over 2 years ago, is your question actually relevant?

Anyway, you can just run the correct migration with fake flag so Django records the migration as done and does not attempt to run the migration SQL. You can log the SQL axes runs by from the django.db logging handler and modify the contents of the migration to your liking, afterwards creating the migration records with the fake migration.

You can refer to e.g. this blog post on handling migrations yourself.