No migrations to apply python

Django 1.7 — «No migrations to apply» when run migrate after makemigrations

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") 

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

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 

Note that most of the answers here are pretty bad especially if you’re dealing with a production database. Make sure you understand the suggestion before tinkering.

23 Answers 23

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.

An answer with «delete all files» in it should be done carefully and sometimes we just can’t/don’t want to delete everything.

if only there would have been and oscar / nobel for tech work. u sir. deserved it 10 years in row!! 🙂

I’d highly suggest to check your migrations first. SELECT * FROM django_migrations; Here you’ll get a list with all migrations. Take the id, and run DELETE FROM django_migrations WHERE django_migrations.id in (id2, id2 . idN)

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.

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

• No changes are made in the DB
• But when I check the db schema, it remains to be the old one

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

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.

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.

1. Modify your models.py to match the new schema (e.i. the schema that you need now)
2. Make new migration by running python manage.py makemigrations your-app-name
3. 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.

Источник

Django Postgres Multiple Schema Migrations: «No migrations to apply»

Oddly, taking these steps (again, on a fresh database) in reverse order works:

• py manage.py migrate —database=other : works as expected and the ‘other’ schema is migrated correctly.
• py manage.py migrate results in: works as expected and the ‘default’ schema is migrated correctly.

I suspect this has something to do with the django_migrations table. I don’t know much about this table, is there one per Postgres schema? Or is there only one django_migrations table per project? After a lot of Googling I saw many suggestions for the use of database routers. The ‘other’ schema must have all the same tables as the ‘default’ schema so a router won’t help in this case.

I have tried executing the SQL DELETE FROM django_migrations after running migrations on ‘default’ and then running migrations on ‘other’; this works only for the first migration on a fresh database, any subsequent migration attempts result in an error as Django tries to apply already applied migrations and raises django.db.utils.ProgrammingError: relation «» already exists .

I have also tried playing around with the django.db.migrations.recorder.MigrationRecorder class to flush the migrations table between migrating the ‘default’ and ‘other’ database, again no luck.

Additionally, the only way I was able to get my test suite to run was to set ‘other’ as a dependency for ‘default’ to exploit the odd fact that migrating ‘other’ before ‘default’ works.

I’m at a loss as to why this is happening, I’m sure there’s something I’m missing.

Update

Taking the same steps as mentioned earlier:

• py manage.py migrate : works as expected and the ‘default’ schema is migrated correctly.
• py manage.py migrate —database=other results in: No migrations to apply.

After some digging around in pgAdmin I ran the following SQL

SET search_path TO default SELECT * FROM django_migrations 

and this returned the table of applied migrations as expected. Then running the following SQL

SET search_path TO other SELECT * FROM django_migrations 

and I got an error saying that the relation «django_migrations» does not exist. So this answers my question regarding the django_migrations table: there should be one per schema and this of course makes perfect sense.

So this leads me to think that Django must be looking at the django_migrations table from the ‘default’ schema when trying to migrate the ‘other’ schema and thus sees that there are «no migrations to apply». I will keep on trying to resolve this, any pointers would go a long way as I am still unsure how to get the migrations working on both schemas.

Update

I had written this as an answer but this solution only worked locally so I have added it as an update instead.

After staring at the DATABASES configuration for a while I finally understood what was causing the issues I was seeing. I had provided a comma separated list for each search_path option like so:

My interpretation of what is going on here: when running py manage.py migrate on a fresh database Django will see that there is no django_migrations table in the ‘default’ schema, create one and then populate it as it applies the migrations. Then when I run py manage.py migrate —database=other it will look in ‘other’ for the django_migrations , not find it and then it must look in ‘default’ as it is the next place to look in the search path. As django_migrations already exists in the ‘default’ schema Django will use this table then see that there are «no migrations to apply». I may not be completely accurate here, please correct me if I have said anything blatantly wrong.

Changing the search paths in the DATABASES configuration like so:

has resulted in both schemas being migrated successfully in my local environment. However, this does not work when migrations are run on TravisCI or Heroku. Both of which give this error upon migration of either ‘default’ or ‘other’:

Traceback (most recent call last): File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/django/db/backends/utils.py", line 83, in _execute return self.cursor.execute(sql) psycopg2.ProgrammingError: no schema has been selected to create in LINE 1: CREATE TABLE "django_migrations" ("id" serial NOT NULL PRIMA. 

Источник

Django — a migration was detected, but saying no migrations to apply

I added a new field slug = models.SlugField(unique=True, null=True) to a model. A new migration was successfully detected.

(venv) 192-168-1-201:shop jinx$ python manage.py makemigrations book Migrations for 'book': book/migrations/0014_book_slug.py - Add field slug to book 

(venv) 192-168-1-201:shop jinx$ python manage.py migrate book Operations to perform: Apply all migrations: book Running migrations: No migrations to apply. 

(venv) 192-168-1-201:shop jinx$ python manage.py migrate --fake book Operations to perform: Apply all migrations: book Running migrations: No migrations to apply. 

I have faced this problem for serval times, but each time I fixed it somehow. Now I want to know what causes this issue? Fields in the model:

class Book(models.Model): title = models.CharField(max_length=191, unique=True) slug = models.SlugField(unique=True, null=True) # new field pub_date = models.DateField() publisher = models.CharField(max_length=191) language = models.CharField(max_length=191) print_length = models.DecimalField(max_digits=6, decimal_places=0) price = models.DecimalField(max_digits=10, decimal_places=2) authors = models.ManyToManyField(Author, related_name='written_by') categories = models.ManyToManyField(Category) quantity = models.IntegerField(default=0) description = models.TextField(null=True) photo = models.ImageField(upload_to='book photos', null=True,blank=True) is_active = models.BooleanField(default=True) created_date = models.DateTimeField(auto_now_add=True, editable=False) last_modified = models.DateTimeField(auto_now=True) 

book [X] 0001_initial [X] 0002_auto_20180819_2147 [X] 0003_auto_20180819_2147 [X] 0004_auto_20180819_2148 [X] 0005_auto_20180819_2151 [X] 0006_auto_20180819_2152 [X] 0007_auto_20180819_2154 [X] 0008_auto_20180819_2155 [X] 0009_auto_20180819_2159 [X] 0010_auto_20180819_2201 [X] 0011_book_photo [X] 0012_auto_20180826_1502 [X] 0013_auto_20180828_2214 [X] 0014_book_slug 

mysql> describe book_book; +---------------+---------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------+---------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | title | varchar(255) | NO | | NULL | | | pub_date | date | NO | | NULL | | | publisher | varchar(255) | NO | | NULL | | | language | varchar(255) | NO | | NULL | | | print_length | decimal(6,0) | NO | | NULL | | | price | decimal(10,2) | NO | | NULL | | | quantity | int(11) | YES | | NULL | | | description | longtext | YES | | NULL | | | created_date | datetime(6) | NO | | NULL | | | is_active | tinyint(1) | NO | | NULL | | | last_modified | datetime(6) | NO | | NULL | | | photo | varchar(100) | YES | | NULL | | +---------------+---------------+------+-----+---------+----------------+ 13 rows in set (0.01 sec) 

from django.db import migrations, models class Migration(migrations.Migration): dependencies = [ ('book', '0013_auto_20180828_2214'), ] operations = [ migrations.AddField( model_name='book', name='slug', field=models.SlugField(null=True, unique=True), ), ] 

Источник