Django 1.7 – makemigrations not detecting changes
Question:
As the title says, I can’t seem to get migrations working.
The app was originally under 1.6, so I understand that migrations won’t be there initially, and indeed if I run python manage.py migrate
I get:
Operations to perform:
Synchronize unmigrated apps: myapp
Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
No migrations to apply.
If I make a change to any models in myapp
, it still says unmigrated, as expected.
But if I run python manage.py makemigrations myapp
I get:
No changes detected in app 'myapp'
Doesn’t seem to matter what or how I run the command, it’s never detecting the app as having changes, nor is it adding any migration files to the app.
Is there any way to force an app onto migrations and essentially say “This is my base to work with” or anything? Or am I missing something?
My database is a PostgreSQL one if that helps at all.
Answers:
Did u use schemamigration my_app --initial
after renaming old migration folder? Try it. Might work. If not – try to recreate the database and make syncdb+migrate. It worked for me…
Ok, looks like I missed an obvious step, but posting this in case anyone else does the same.
When upgrading to 1.7, my models became unmanaged (managed = False
) – I had them as True
before but seems it got reverted.
Removing that line (To default to True) and then running makemigrations
immediately made a migration module and now it’s working. makemigrations
will not work on unmanaged tables (Which is obvious in hindsight)
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 tells you to do is python manage.py makemigrations
which will fail. The initial migration is done when you create your app in version 1.7, but if you came from 1.6 it wouldn’t have been carried out. See the ‘Adding migration to apps’ in the documentation for more details.
I had the same problem with having to run makemigrations twice and all sorts of strange behaviour. It turned out the root of the problem was that I was using a function to set default dates in my models so migrations was detecting a change every time I ran makemigrations. The answer to this question put me on the right track: Avoid makemigrations to re-create date field
My solution was not covered here so I’m posting it. I had been using syncdb
for a project–just to get it up and running. Then when I tried to start using Django migrations, it faked them at first then would say it was ‘OK’ but nothing was happening to the database.
My solution was to just delete all the migration files for my app, as well as the database records for the app migrations in the django_migrations
table.
Then I just did an initial migration with:
./manage.py makemigrations my_app
followed by:
./manage.py migrate my_app
Now I can make migrations without a problem.
Maybe this will help someone. I was using a nested app. project.appname and I actually had project and project.appname in INSTALLED_APPS. Removing project from INSTALLED_APPS allowed the changes to be detected.
You want to check the settings.py
in the INSTALLED_APPS
list and make sure all the apps with models are listed in there.
Running makemigrations
in the project folder means it will look to update all the tables related to all the apps included in settings.py
for the project. Once you include it, makemigrations
will automatically include the app (this saves a lot of work so you don’t have to run makemigrations app_name
for every app in your project/site).
The answer is on this stackoverflow post, by cdvv7788 Migrations in Django 1.7
If it is the first time you are migrating that app you have to use:
manage.py makemigrations myappname Once you do that you can do:
manage.py migrate If you had your app in database, modified its model
and its not updating the changes on makemigrations you probably havent
migrated it yet. Change your model back to its original form, run the
first command (with the app name) and migrate…it will fake it. Once
you do that put back the changes on your model, run makemigrations and
migrate again and it should work.
I was having the exact same trouble and doing the above worked perfectly.
I had moved my django app to cloud9 and for some reason I never caught the initial migration.
Just in case you have a specific field that does not get identified by makemigrations: check twice if you have a property with the same name.
example:
field = django.db.models.CharField(max_length=10, default = '', blank=True, null=True)
# ... later
@property
def field(self):
pass
the property will “overwrite” the field definition so changes will not get identified by makemigrations
This is kind of a stupid mistake to make, but having an extra comma at the end of the field declaration line in the model class, makes the line have no effect.
It happens when you copy paste the def. from the migration, which itself is defined as an array.
Though maybe this would help someone 🙂
People like me who don’t like migrations can use steps below.
- Remove changes what you want to sync.
- Run
python manage.py makemigrations app_label
for the initial migration.
- Run
python manage.py migrate
for creating tables before you make changes.
- Paste changes which you remove at first step.
- Run 2. and 3. steps.
If you confused any of these steps, read the migration files. Change them to correct your schema or remove unwanted files but don’t forget to change next migration file’s dependencies part 😉
I hope this will help someone in future.
Agree with @furins. If everything seems to be in order and yet this problem arises, checkout if there is any property method with same title as the attribute which you are trying to add in the Model class.
- Remove method with similar name as attribute you are adding.
- manage.py makemigrations my_app
- manage.py migrate my_app
- Add the methods back.
Adding this answer because only this method helped me.
I deleted the migrations
folder run makemigrations
and migrate
.
It still said: No migrations to apply.
I went to migrate
folder and opened the last created file,
comment the migration I wanted(It was detected and entered there)
and run migrate
again.
This basically editing the migrations file manually.
Do this only if you understand the file content.
Following worked for me:
- Add the app name to settings.py
- use ‘python manage.py makemigrations’
- use ‘python manage.py migrate’
Worked for me: Python 3.4, Django 1.10
Make sure your model is not abstract
. I actually made that mistake and it took a while, so I thought I’d post it.
I recently upgraded Django from 1.6 to 1.8 and had few apps and migrations for them. I used south and schemamigrations
for creating migrations in Django 1.6, which is dropped in Django 1.8.
When I added new models after upgrade, the makemigrations
command wasn’t detecting any changes. And then I tried the solution suggested by @drojf (1st answer), it worked fine, but failed to apply fake initial migration (python manage.py --fake-initial
). I was doing this as my tables (old tables) were already created.
Finally this worked for me, removed new models (or model changes) from models.py and then had to delete (or rename for safety backup) migrations folder of all apps and run python manage.py
makemigrations for all apps, then did python manage.py migrate --fake-initial
. This worked like a charm. Once initial migration is created for all apps and fake initial migrated, then added new models and followed regular process of makemigrations
and migrate on that app. The changes were detected now and everything went fine.
I just thought of sharing it here, if someone faces same problem (having schemamigrations
of south for their apps), it might help them 🙂
Maybe that can help someone, I had the same problem.
I’ve already created two tables with the serializer class and the views.
So when I wanted to updated, I had this error.
I followed this steps:
- I made
.manage.py makemigrations app
- I executed
.manage.py migrate
- I erased both tables of my
models.py
- I erased all reference to my tables from serializer and view class.
- I executed step
1
and 2
.
- I retrieved my changes just in the
models.py
- I executed again step
5
.
- I restored all my changes.
If you’re working with Pycharm, local history is very helpfull.
Maybe this will help someone.
I’ve deleted my models.py
and expected makemigrations
to create DeleteModel
statements.
Remember to delete *.pyc
files!
Maybe I am too late but did you try to have a migrations
folder in your app with a __init__.py
file in it?
./manage makemigrations
./manage migrate
Migrations track changes to DB so if youre changing from unmanaged to managed, you’ll need to make sure that youre database table is up to date relating to the Model you’re dealing with.
If you are still in dev mode, I personally decided to delete the migration files in my IDE as well as in the django_migrations table relating to my Model and rerun the above command.
REMEMBER: if you have a migration that ends with _001 in your IDE & _003 in your database. Django will only see if you have a migration ending with _004 for anything to update.
The 2 (code & db migrations) are linked and work in tandem.
Happy coding.
Adding my 2c, since none of these solutions worked for me, but this did…
I had just run manage.py squashmigrations
and removed the old migrations (both the files and lines in the the django.migrations database table).
This left a line like this in the last migration file:
replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]
This apparently confused Django and caused weird behavior: running manage.py makemigrations my_app
would recreate the initial migration as if none existed. Removing the replaces...
line fixed the problem!
This may happen due to the following reasons:
- You did not add the app in
INSTALLED_APPS
list in settings.py
(You have to add either the app name or the dotted path to the subclass of AppConfig in apps.py in the app folder, depending on the version of django you are using). Refer documentation: INSTALLED_APPS
- You don’t have
migrations
folder inside those apps. (Solution: just create that folder).
- You don’t have
__init__.py
file inside migrations
folder of those apps. (Solution: Just create an empty file with name __init__.py
)
- You don’t have an
__init__.py
file inside the app folder. (Solution: Just create an empty file with name __init__.py
)
- You don’t have a
models.py
file in the app
- Your Python class (supposed to be a model) in
models.py
doesn’t inherit django.db.models.Model
- You have some semantic mistake in definition of models in
models.py
Note:
A common mistake is to add migrations
folder in .gitignore
file. When cloned from remote repo, migrations
folder and/or __init__.py
files will be missing in local repo. This causes problem.
Migration files are supposed to be included in the repo. read here. If your team frequently faces migration issues you may consider ignoring migration files as follows:
I suggest to gitignore migration files by adding the following lines to .gitignore
file
*/migrations/*
!*/migrations/__init__.py
Remember, it is not recommended to gitignore migration files as per django documentation
Added this answer because none of other available above worked for me.
In my case something even more weird was happening (Django 1.7 Version), In my models.py I had an “extra” line at the end of my file (it was a blank line) and when I executed the python manage.py makemigrations
command the result was: “no changes detected”.
To fix this I deleted this “blank line” that was at the end of my models.py file and I did run the command again, everything was fixed and all the changes made to models.py were detected!
Had the same problem
Make sure whatever classes you have defined in models.py, you must have to inherit models.Model class.
class Product(models.Model):
title = models.TextField()
description = models.TextField()
price = models.TextField()
You may need to fake the initial migrations using the command below
python manage.py migrate --fake-initial
First this solution is applicable to those who are facing the same issue during deployment on heroku server, I was facing same issue.
To deploy, there is a mandatory step which is to add django_heroku.settings(locals()) in settings.py file.
Changes:
When I changed the above line to django_heroku.settings(locals(), databases=False), it worked flawlessly.
python manage.py makemigrations accounts
Migrations for ‘accounts’:
accountsmigrations 001_initial.py
– Create model Customer
– Create model Tag
– Create model Product
– Create model Order
Note: here “accounts” is my app name
- Remove changes what you want to sync.
- Run python manage.py makemigrations app_label for the initial migration.
- Run python manage.py migrate for creating tables before you make changes.
- Paste changes which you remove at first step.
- Run 2. and 3. steps
In my case I needed to add my model to the _init_.py file of the models folder where my model was defined:
from myapp.models.mymodel import MyModel
I have encountered this issue, the command
python manage.py makemigrations
worked with me once I saved the changes that I made on the files.
One of the cause may be You didn’t register your models in admin.py file .
First register your models in admin.py file then do the migrations.
I had mistakely deleted folder of migrations
from my project directory.
Solution is to create __init__.py
file in the migrations
folder, and then,
python manage.py makemigrations
python manage.py migrate
Load ur app to settings.py and py .manage.py makemigrations
INSTALLED_APPS = [
'appname'
]
for me i remove migrations files on env folder envLibsite-packagesdjangocontribauthmigrations...
but keep the __init__.py
don’t remove it
sometime/somehow you get into situation where django understands that migration is already applied and when you run migrations it will say "No changes detected"
in this situation follow these steps:
First make sure that your app is registered on
INSTALLED_APPS
of your project settings.py file.
If your migrations don’t apply to your project you can run
python manage.py makemigrations {app_name}
then apply to migrate the command
python manage.py migrate
or
python manage.py migrate {app_name}
if migrations are applied but migrate command is not applied, check your database, there will be a table called "django_migrations". Then check whether your newly added migrations file exists in this table or not. If exists remove this row and apply to migrate command again. Hope it will work.
As the title says, I can’t seem to get migrations working.
The app was originally under 1.6, so I understand that migrations won’t be there initially, and indeed if I run python manage.py migrate
I get:
Operations to perform:
Synchronize unmigrated apps: myapp
Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
No migrations to apply.
If I make a change to any models in myapp
, it still says unmigrated, as expected.
But if I run python manage.py makemigrations myapp
I get:
No changes detected in app 'myapp'
Doesn’t seem to matter what or how I run the command, it’s never detecting the app as having changes, nor is it adding any migration files to the app.
Is there any way to force an app onto migrations and essentially say “This is my base to work with” or anything? Or am I missing something?
My database is a PostgreSQL one if that helps at all.
Did u use schemamigration my_app --initial
after renaming old migration folder? Try it. Might work. If not – try to recreate the database and make syncdb+migrate. It worked for me…
Ok, looks like I missed an obvious step, but posting this in case anyone else does the same.
When upgrading to 1.7, my models became unmanaged (managed = False
) – I had them as True
before but seems it got reverted.
Removing that line (To default to True) and then running makemigrations
immediately made a migration module and now it’s working. makemigrations
will not work on unmanaged tables (Which is obvious in hindsight)
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 tells you to do is python manage.py makemigrations
which will fail. The initial migration is done when you create your app in version 1.7, but if you came from 1.6 it wouldn’t have been carried out. See the ‘Adding migration to apps’ in the documentation for more details.
I had the same problem with having to run makemigrations twice and all sorts of strange behaviour. It turned out the root of the problem was that I was using a function to set default dates in my models so migrations was detecting a change every time I ran makemigrations. The answer to this question put me on the right track: Avoid makemigrations to re-create date field
My solution was not covered here so I’m posting it. I had been using syncdb
for a project–just to get it up and running. Then when I tried to start using Django migrations, it faked them at first then would say it was ‘OK’ but nothing was happening to the database.
My solution was to just delete all the migration files for my app, as well as the database records for the app migrations in the django_migrations
table.
Then I just did an initial migration with:
./manage.py makemigrations my_app
followed by:
./manage.py migrate my_app
Now I can make migrations without a problem.
Maybe this will help someone. I was using a nested app. project.appname and I actually had project and project.appname in INSTALLED_APPS. Removing project from INSTALLED_APPS allowed the changes to be detected.
You want to check the settings.py
in the INSTALLED_APPS
list and make sure all the apps with models are listed in there.
Running makemigrations
in the project folder means it will look to update all the tables related to all the apps included in settings.py
for the project. Once you include it, makemigrations
will automatically include the app (this saves a lot of work so you don’t have to run makemigrations app_name
for every app in your project/site).
The answer is on this stackoverflow post, by cdvv7788 Migrations in Django 1.7
If it is the first time you are migrating that app you have to use:
manage.py makemigrations myappname Once you do that you can do:
manage.py migrate If you had your app in database, modified its model
and its not updating the changes on makemigrations you probably havent
migrated it yet. Change your model back to its original form, run the
first command (with the app name) and migrate…it will fake it. Once
you do that put back the changes on your model, run makemigrations and
migrate again and it should work.
I was having the exact same trouble and doing the above worked perfectly.
I had moved my django app to cloud9 and for some reason I never caught the initial migration.
Just in case you have a specific field that does not get identified by makemigrations: check twice if you have a property with the same name.
example:
field = django.db.models.CharField(max_length=10, default = '', blank=True, null=True)
# ... later
@property
def field(self):
pass
the property will “overwrite” the field definition so changes will not get identified by makemigrations
This is kind of a stupid mistake to make, but having an extra comma at the end of the field declaration line in the model class, makes the line have no effect.
It happens when you copy paste the def. from the migration, which itself is defined as an array.
Though maybe this would help someone 🙂
People like me who don’t like migrations can use steps below.
- Remove changes what you want to sync.
- Run
python manage.py makemigrations app_label
for the initial migration. - Run
python manage.py migrate
for creating tables before you make changes. - Paste changes which you remove at first step.
- Run 2. and 3. steps.
If you confused any of these steps, read the migration files. Change them to correct your schema or remove unwanted files but don’t forget to change next migration file’s dependencies part 😉
I hope this will help someone in future.
Agree with @furins. If everything seems to be in order and yet this problem arises, checkout if there is any property method with same title as the attribute which you are trying to add in the Model class.
- Remove method with similar name as attribute you are adding.
- manage.py makemigrations my_app
- manage.py migrate my_app
- Add the methods back.
Adding this answer because only this method helped me.
I deleted the migrations
folder run makemigrations
and migrate
.
It still said: No migrations to apply.
I went to migrate
folder and opened the last created file,
comment the migration I wanted(It was detected and entered there)
and run migrate
again.
This basically editing the migrations file manually.
Do this only if you understand the file content.
Following worked for me:
- Add the app name to settings.py
- use ‘python manage.py makemigrations’
- use ‘python manage.py migrate’
Worked for me: Python 3.4, Django 1.10
Make sure your model is not abstract
. I actually made that mistake and it took a while, so I thought I’d post it.
I recently upgraded Django from 1.6 to 1.8 and had few apps and migrations for them. I used south and schemamigrations
for creating migrations in Django 1.6, which is dropped in Django 1.8.
When I added new models after upgrade, the makemigrations
command wasn’t detecting any changes. And then I tried the solution suggested by @drojf (1st answer), it worked fine, but failed to apply fake initial migration (python manage.py --fake-initial
). I was doing this as my tables (old tables) were already created.
Finally this worked for me, removed new models (or model changes) from models.py and then had to delete (or rename for safety backup) migrations folder of all apps and run python manage.py
makemigrations for all apps, then did python manage.py migrate --fake-initial
. This worked like a charm. Once initial migration is created for all apps and fake initial migrated, then added new models and followed regular process of makemigrations
and migrate on that app. The changes were detected now and everything went fine.
I just thought of sharing it here, if someone faces same problem (having schemamigrations
of south for their apps), it might help them 🙂
Maybe that can help someone, I had the same problem.
I’ve already created two tables with the serializer class and the views.
So when I wanted to updated, I had this error.
I followed this steps:
- I made
.manage.py makemigrations app
- I executed
.manage.py migrate
- I erased both tables of my
models.py
- I erased all reference to my tables from serializer and view class.
- I executed step
1
and2
. - I retrieved my changes just in the
models.py
- I executed again step
5
. - I restored all my changes.
If you’re working with Pycharm, local history is very helpfull.
Maybe this will help someone.
I’ve deleted my models.py
and expected makemigrations
to create DeleteModel
statements.
Remember to delete *.pyc
files!
Maybe I am too late but did you try to have a migrations
folder in your app with a __init__.py
file in it?
./manage makemigrations
./manage migrate
Migrations track changes to DB so if youre changing from unmanaged to managed, you’ll need to make sure that youre database table is up to date relating to the Model you’re dealing with.
If you are still in dev mode, I personally decided to delete the migration files in my IDE as well as in the django_migrations table relating to my Model and rerun the above command.
REMEMBER: if you have a migration that ends with _001 in your IDE & _003 in your database. Django will only see if you have a migration ending with _004 for anything to update.
The 2 (code & db migrations) are linked and work in tandem.
Happy coding.
Adding my 2c, since none of these solutions worked for me, but this did…
I had just run manage.py squashmigrations
and removed the old migrations (both the files and lines in the the django.migrations database table).
This left a line like this in the last migration file:
replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]
This apparently confused Django and caused weird behavior: running manage.py makemigrations my_app
would recreate the initial migration as if none existed. Removing the replaces...
line fixed the problem!
This may happen due to the following reasons:
- You did not add the app in
INSTALLED_APPS
list insettings.py
(You have to add either the app name or the dotted path to the subclass of AppConfig in apps.py in the app folder, depending on the version of django you are using). Refer documentation: INSTALLED_APPS - You don’t have
migrations
folder inside those apps. (Solution: just create that folder). - You don’t have
__init__.py
file insidemigrations
folder of those apps. (Solution: Just create an empty file with name__init__.py
) - You don’t have an
__init__.py
file inside the app folder. (Solution: Just create an empty file with name__init__.py
) - You don’t have a
models.py
file in the app - Your Python class (supposed to be a model) in
models.py
doesn’t inheritdjango.db.models.Model
- You have some semantic mistake in definition of models in
models.py
Note:
A common mistake is to add migrations
folder in .gitignore
file. When cloned from remote repo, migrations
folder and/or __init__.py
files will be missing in local repo. This causes problem.
Migration files are supposed to be included in the repo. read here. If your team frequently faces migration issues you may consider ignoring migration files as follows:
I suggest to gitignore migration files by adding the following lines to .gitignore
file
*/migrations/*
!*/migrations/__init__.py
Remember, it is not recommended to gitignore migration files as per django documentation
Added this answer because none of other available above worked for me.
In my case something even more weird was happening (Django 1.7 Version), In my models.py I had an “extra” line at the end of my file (it was a blank line) and when I executed the python manage.py makemigrations
command the result was: “no changes detected”.
To fix this I deleted this “blank line” that was at the end of my models.py file and I did run the command again, everything was fixed and all the changes made to models.py were detected!
Had the same problem
Make sure whatever classes you have defined in models.py, you must have to inherit models.Model class.
class Product(models.Model):
title = models.TextField()
description = models.TextField()
price = models.TextField()
You may need to fake the initial migrations using the command below
python manage.py migrate --fake-initial
First this solution is applicable to those who are facing the same issue during deployment on heroku server, I was facing same issue.
To deploy, there is a mandatory step which is to add django_heroku.settings(locals()) in settings.py file.
Changes:
When I changed the above line to django_heroku.settings(locals(), databases=False), it worked flawlessly.
python manage.py makemigrations accounts
Migrations for ‘accounts’:
accountsmigrations 001_initial.py
– Create model Customer
– Create model Tag
– Create model Product
– Create model Order
Note: here “accounts” is my app name
- Remove changes what you want to sync.
- Run python manage.py makemigrations app_label for the initial migration.
- Run python manage.py migrate for creating tables before you make changes.
- Paste changes which you remove at first step.
- Run 2. and 3. steps
In my case I needed to add my model to the _init_.py file of the models folder where my model was defined:
from myapp.models.mymodel import MyModel
I have encountered this issue, the command
python manage.py makemigrations
worked with me once I saved the changes that I made on the files.
One of the cause may be You didn’t register your models in admin.py file .
First register your models in admin.py file then do the migrations.
I had mistakely deleted folder of migrations
from my project directory.
Solution is to create __init__.py
file in the migrations
folder, and then,
python manage.py makemigrations
python manage.py migrate
Load ur app to settings.py and py .manage.py makemigrations
INSTALLED_APPS = [ 'appname' ]
for me i remove migrations files on env folder envLibsite-packagesdjangocontribauthmigrations...
but keep the __init__.py
don’t remove it
sometime/somehow you get into situation where django understands that migration is already applied and when you run migrations it will say "No changes detected"
in this situation follow these steps:
First make sure that your app is registered on
INSTALLED_APPS
of your project settings.py file.
If your migrations don’t apply to your project you can run
python manage.py makemigrations {app_name}
then apply to migrate the command
python manage.py migrate
or
python manage.py migrate {app_name}
if migrations are applied but migrate command is not applied, check your database, there will be a table called "django_migrations". Then check whether your newly added migrations file exists in this table or not. If exists remove this row and apply to migrate command again. Hope it will work.