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

Question

I use Django1.7 with Mezzanine. I create simple profile (according to Mezzanine documentation) stored in separate app "profiles":

class RoadmapProfile(models.Model):
    user = models.OneToOneField("auth.User")
    fullname = models.CharField(max_length=100, verbose_name="Full name")

Creation of migrations returns:

  Migrations for 'profiles':
      0001_initial.py:
        - Create model RoadmapProfile

When I run "migrate profiles":

Operations to perform:
  Apply all migrations: profiles
Running migrations:
  No migrations to apply.

The issue is, when I try to open any page related to mezzanine.accounts (for example update account), it crashes with:

OperationalError at /accounts/update/

no such column: profiles_roadmapprofile.fullname

What I have done wrong?

Answer 1

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 (Here, use the command "python manage.py inspectdb". This command is like reverse migration. It generates the corresponding models.py for the current database tables schema.)

• 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.

Answer 2

In case you are using docker and trying something like:

docker-compose exec SERVICE_NAME python manage.py migrate

Check that you've restated a container:

docker-compose up --build --force-recreate SERVICE_NAME -d

Because manage.py migrate will look changes inside container, not in "current dir".

That was my case)

Answer 3

If you execute the migrate command again and there are no unapplied migrations, the command will output the following:

Operations to perform: Apply all migrations: admin, auth, blog, contenttypes, sessions, users Running migrations: No migrations to apply.

To list the project migrations and their status, you use the showmigrations command:

python manage.py showmigrations

Answer 4

Make sure to register your model in admin.py if you haven't:

from .models import RoadmapProfile

admin.site.register(RoadmapProfile)

then migrate:

python manage.py makemigrations profile
python manage.py migrate

If this still doesn't fix the issue, you may want to fake a migration.

python manage.py migrate --fake

Answer 5

i solved it after hours research delete the app and create it again using python manage.py startapp your app name then register on the setting.py

Answer 6

I had this problem few hours ago. For me, my migration folder was outside my app so I was unable to run any migrations as Django keeps saying No changes made. Moving the migration folder under my API app worked for me.

Answer 7

Two steps:

1.to go database:

 DROP TABLE django_migrations;

2.remove all the migration files in migrations folder ,and then do makemigrations and migrate again

Answer 8

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.

Answer 9

I had the same issue with postgress , deleting django_migrations database solved the issue

Answer 10

All I did was delete the last line of the django-migrations table. It was clear this was the right migration to delete because its name was the same as the migration I generated but could not apply.

Answer 11

The pb with the solutions is that you must delete your data. If you want to avoid that + you are using Sqlite , follow the process:

1. Download SQLITEStudio
2. Open SqliteStudio, and link it to you project db
3. click on the table you wish to modify, and add column ( same as in your model)

Answer 12

This is a very confusing topic. django stores all applied migrations in a table called django_migrations. perform this sql ( i am using postgres . so in query tool section)

select * from django_migrations where app='your appname'  (app in which u have issue with).

This will list all applied migrations for that app.
Go to your app/migration folder and check all migrations . find the migration file associated with your error . file where your table was created or column added or modified.
look for the id of this migration file in django_migrations table( select * from django_migrations where app='your app') .

Then do :

delete from django_migrations where id='id of your migration';

delete multiple id's if you have multiple migrations file associated with your issue.

now reapply migrate

Python manage.py migrate yourappname

second option

1. Drop tables in your app where you have issue.

2. delete all migrations for that app from app/migrations folder.(don't delete init.py from that folder).

3. now run

   python manage.py makemigrations appname

4. now run

python manage.py migrate appname

Answer 13

The same problem happened to me using PostgreSQL I cleared all migrations in migrations folder and in migrations cache folder, and then in my PGADMIN ran:

delete from django_migrations where app='your_app'

Answer 14

if you are using GIT for control versions and in some of yours commit you added db.sqlite3, GIT will keep some references of the database, so when you execute 'python manage.py migrate', this reference will be reflected on the new database. I recommend to execute the following command:

git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch 'db.sqlite3' HEAD

it worked for me :)

Answer 15

The problem here are fake migrations somewhere. Basically in your database the table created from your model doesn't exist, tho somewhere in time that table existed before, due an old update o whatever it may be. The problem is that django already made those migrations so the tables MUST exist for hence overlooking migrations but getting error "table_doesnt_exist" in Admin.

Solution:

1.- Make sure to save any data from that model.

2.- Access your database and run this query.

 SELECT * FROM django_migrations;

3.- Get the id from the list generated from the query. These are migrations that Django has migrated so far, hence TABLES MUST EXIST. In your case I'd look for a row named roadmapprofile, due this is the name of your model.

4.- Now lets delete this row from this table using the ids,

 DELETE FROM django_migrations where django_migrations.id in (value_id1, value_id2 ... value_idN);

Replace value_id1 and value_id2 with respective ids. It could be only one or many so don't worry if you don't see more than 1 id, what this means is that only one model exists under the current app.

5.- Migrate app to zero

 manage.py migrate <app_name> zero

6.- Delete all migrations files within the app migrations folder

7.- Create Migrations

 manage.py makemigrations

8.- Once you delete these registries and run manage.py migrate; Django will be forced to run migrations for these models due "MIGRATIONS WON'T EXIST" for these models.

 manage.py migrate

That's it. You shouldn't have any problems following these instructions. By the way, you shouldn't loose any data from other models due you're only migrating and updating tables related to these specific models.

Answer 16

Maybe your model not linked when migration process is ongoing. Try to import it in file urls.py from models import your_file

Answer 17

For me, none of the offered solutions worked. It turns out that I was using different settings for migration (manage.py) and running (wsgi.py). Settings defined in manage.py used a local database however a production database was used in wsgi.py settings. Thus a production database was never migrated. Using:

django-admin migrate

for migration proved to be better as you have to specify the settings used as here.

• Make sure that when migrating you always use the same database as when running!

Answer 18

I had this same problem. Make sure the app's migrations folder is created (YOURAPPNAME/ migrations). Delete the folder and enter the commands:

python manage.py migrate --fake
python manage.py makemigrations <app_name>
python manage.py migrate --fake-initial

I inserted this lines in each class in models.py:

class Meta:
    app_label = '<app_name>'

This solved my problem.

Answer 19

@phanhuy152 has the best answer. Just to add my two cents:

His solution is:

1. Delete migration history in DB
2. Delete migrations folder
3. Edit your model to be consistent with DB before your change
4. makemigrations to restore the initial state of the migration files
5. Then, change the model as you like
6. makemigrations again
7. migrate to apply updates to table.

But in my case, I have several models in the models.py file and at the last step, Django complains about Table xxx already exists, because the initial migrations files intends to create the xxx table again, when we just don't (and don't want to)drop other tables.

In this case, in order to preserve the data, we must tell Django to leave them alone in migrate. We just do: (assume that class A is the one we change, and class B, C remain same):

models.py:

from django.db import models

class A(models.Models):
    ...

class B(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

    ...

class C(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

Add these lines after we construct the initial migrations.

So, the process now is:

1. ...
2. ...
3. ...
4. ...
5. Add managed = False to other classes
6. makemigrations to apply Meta changes. You will see something like:

output:

Migrations for 'backEnd':
  backEnd/migrations/0002_auto_20180412_1654.py
    - Change Meta options on toid
    - Change Meta options on tprocessasinc
    - Change Meta options on tservers
    - Change Meta options on tsnmpserver

7. migrate to apply them in DB
8. Change your model now: add a field, change the type, etc.
9. migrate again.
10. Delete the Meta class to let Django manage other class again. makemigrations, migrate again.

Now you have all the structure and data of your models, without losing the part formerly stored in DB.

Answer 20

python manage.py migrate --fake APPNAME zero

This will make your migration to fake. Now you can run the migrate script

python manage.py migrate APPNAME

Tables will be created and you solved your problem.. Cheers!!!

Answer 21

In my case I wrote like this:

python manage.py makemigrations --empty yourappname

python manage.py migrate yourappname

or:

Django keeps track of all the applied migrations in django_migrations table. So just delete all the rows in the django_migrations table that are related to you app like:

DELETE FROM django_migrations WHERE app='your-app-name'

and then do:

python manage.py makemigrations python manage.py migrate

Answer 22

My issue was that there was no __init__.py file in the same folder as the migrations. On adding the __init__.py to the folder which contained them, manage.py migrate found and ran them.

Answer 23

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

Answer 24

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.