I got this. I just figured this out and it is good. First, to clear migrations table: ./manage.py migrate –fake <app-name> zero Remove app-name/migrations/ folder or contents. Make the migrations: ./manage.py makemigrations <app-name> Finally tidy up your migrations without making other database changes: ./manage.py migrate –fake <app-name>
If you are using your django project applications in standalone scripts, in other words, without using manage.py – you need to manually call django.setup() first – it would configure the logging and, what is important – populate apps registry. Quote from Initialization process docs: setup() This function is called automatically: When running an HTTP server … Read more
If you have the table created in the database, you can run python manage.py migrate –fake <appname> Mark migrations as run without actually running them Or if you want to avoid some actions in your migration, you can edit the migration file under the app/migrations directory and comment the operations you don’t want to do … Read more
If you’re changing over from an existing app you made in django 1.6, then you need to do one pre-step (as I found out) listed in the documentation: python manage.py makemigrations your_app_label The documentation does not make it obvious that you need to add the app label to the command, as the first thing it … Read more
The problem is that with the changes to apps in Django 1.7, apps are required to have a unique label. By default the app label is the package name, so if you’ve got a package with the same name as one of your app modules (foo in this case), you’ll hit this error. The solution … Read more