Django 1.7 - "No migrations to apply" when run migrate after makemigrations

1. In MySQL Database delete row 'profiles' from the table 'django_migrations'.
2. Delete all migration files in migrations folder.
3. Try again python manage.py makemigrations and python manage.py migrate command.

1- run python manage.py makemigrations <appname>

2- run python manage.py sqlmigrate <appname> <migrationname> - you will find migrationname in migration folder under appname (without '.py' extension of course)

3- copy all text of result # all sql commands that generated
4- go to your db ide and paste as new query and run it

now all changes are applied on your db

Sounds like your initial migration was faked because the table already existed (probably with an outdated schema):

https://docs.djangoproject.com/en/1.8/topics/migrations/#adding-migrations-to-apps

"This will make a new initial migration for your app. Now, when you run migrate, Django will detect that you have an initial migration and that the tables it wants to create already exist, and will mark the migration as already applied."

Otherwise you would get an no-such-table error :)

Did you clean up the applied-migrations table? That's also a common cause for non-applied migrations.

I am a Django newbie and I was going through the same problem. These answers didn't work for me. I wanted to share how did I fix the problem, probably it would save someone lots of time.

Situation:

I make changes to a model and I want to apply these changes to the DB.

What I did:

Run on shell:

python manage.py makemigrations app-name
python manage.py migrate app-name

What happened:

• No changes are made in the DB

• But when I check the db schema, it remains to be the old one

Reason:

• When I run python manage.py migrate app-name, Django checks in django_migrations table in the db to see which migrations have been already applied and will skip those migrations.

What I tried:

Delete the record with app="my-app-name" from that table (delete from django_migrations where app = "app-name"). Clear my migration folder and run python manage.py makemigration my-app-name, then python manage.py migrate my-app-name. This was suggested by the most voted answer. But that doesn't work either.

Why?

Because there was an existing table, and what I am creating was a "initial migration", so Django decides that the initial migration has already been applied (Because it sees that the table already exists). The problem is that the existing table has a different schema.

Solution 1:

Drop the existing table (with the old schema), make initial migrations, and applied again. This will work (it worked for me) since we have an "initial migration" and there was no table with the same name in our db. (Tip: I used python manage.py migrate my-app-name zero to quickly drop the tables in the db)

Problem? You might want to keep the data in the existing table. You don't want to drop them and lose all of the data.

Solution 2:

1. Delete all the migrations in your app and in django_migrations all the fields with django_migrations.app = your-app-name How to do this depends on which DB you are using Example for MySQL: delete from django_migrations where app = "your-app-name";

2. Create an initial migration with the same schema as the existing table, with these steps:

   • Modify your models.py to match with the current table in your database

   • Delete all files in "migrations"

   • Run python manage.py makemigrations your-app-name

   • If you already have an existing database then run python manage.py migrate --fake-initial and then follow the step below.

3. Modify your models.py to match the new schema (e.i. the schema that you need now)

4. Make new migration by running python manage.py makemigrations your-app-name

5. Run python manage.py migrate your-app-name

This works for me. And I managed to keep the existing data.

More thoughts:

The reason I went through all of those troubles was that I deleted the files in some-app/migrations/ (the migrations files). And hence, those migration files and my database aren't consistent with one another. So I would try not modifying those migration files unless I really know what I am doing.