I was trying to create migrations within an existing app using the makemigrations command but it outputs “No changes detected”.
Usually I create new apps using the
startapp command but did not use it for this app when I created it.
After debugging, I found that it is not creating migration because the
migrations package/folder is missing from an app.
Would it be better if it creates the folder if it is not there or am I missing something?
To create initial migrations for an app, run
makemigrations and specify the app name. The migrations folder will be created.
./manage.py makemigrations <myapp>
Your app must be included in
INSTALLED_APPS first (inside settings.py).
My problem (and so solution) was yet different from those described above.
I wasn’t using
models.py file, but created a
models directory and created the
my_model.py file there, where I put my model. Django couldn’t find my model so it wrote that there are no migrations to apply.
My solution was: in the
my_app/models/__init__.py file I added this line:
from .my_model import MyModel
There are multiple possible reasons for django not detecting what to migrate during the
- migration folder You need a migrations package in your app.
- INSTALLED_APPS You need your app to be specified in the
- Verbosity start by running
makemigrations -v 3for verbosity. This might shed some light on the problem.
- Full path In
INSTALLED_APPSit is recommended to specify the full module app config path ‘apply.apps.MyAppConfig’
- –settings you might want to make sure the correct settings file is set:
manage.py makemigrations --settings mysite.settings
- specify app name explicitly put the app name in
manage.py makemigrations myapp– that narrows down the migrations for the app alone and helps you isolate the problem.
model meta check you have the right
app_labelin your model meta
Debug django debug django core script. makemigrations command is pretty much straight forward. Here’s how to do it in pycharm. change your script definition accordingly (ex:
makemigrations --traceback myapp)
- Db Router when working with django db router, the router class (your custom router class) needs to implement the
makemigrations always creates migrations for model changes, but if
allow_migrate() returns False,
I’ve read many answers to this question often stating to simply run
makemigrations in some other ways. But to me, the problem was in the
Meta subclass of models.
I have an app config that says
label = <app name> (in the
apps.py file, beside
views.py etc). If by any chance your meta class doesn’t have the same label as the app label (for instance because you are splitting one too big app into multiple ones), no changes are detected (and no helpful error message whatsoever). So in my model class I have now:
class ModelClassName(models.Model): class Meta: app_label="<app name>" # <-- this label was wrong before. field_name = models.FloatField() ...
Running Django 1.10 here.
I had another problem not described here, which drove me nuts.
class MyModel(models.Model): name = models.CharField(max_length=64, null=True) # works language_code = models.CharField(max_length=2, default="en") # works is_dumb = models.BooleanField(default=False), # doesn't work
I had a trailing ‘,’ in one line perhaps from copy&paste. The line with is_dumb doesn’t created a model migration with ‘./manage.py makemigrations’ but also didn’t throw an error. After removing the ‘,’ it worked as expected.
So be careful when you do copy&paste 🙂
It is a comment but should probably be an answer.
Make sure that your app name is in settings.py
INSTALLED_APPS otherwise no matter what you do it will not run the migrations.
INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'blog', ]
./manage.py makemigrations blog
- Make sure your app is mentioned in installed_apps in settings.py
- Make sure you model class extends models.Model
There are sometimes when
./manage.py makemigrations is superior to
./manage.py makemigrations <myapp> because it can handle certain conflicts between apps.
Those occasions occur silently and it takes several hours of
swearing to understand the real meaning of the dreaded
No changes detected message.
Therefore, it is a far better choice to make use of the following command:
./manage.py makemigrations <myapp1> <myapp2> ... <myappN>
My problem was much simpler than the above answers and probably a far more common reason as long as your project is already set up and working. In one of my applications that had been working for a long time, migrations seemed wonky, so in a hurry, I did the following:
rm -r */migrations/* rm db.sqlite3 python3 manage.py makemigrations No changes detected
I had mistakenly also removed all the
__init__.py files 🙁 – Everything was working again after I went in and:
For each of my applications then the
makemigrations worked again.
It turns out that I had manually created a new application by copying another and forgot to put the
__init__.py in the
migrations folder and that confinved me that everything was wonky – leading my making it worse with an
rm -r as described above.
Hope this helps someone from swearing at the “No changes detected” error for a few hours.
I had copied a table in from outside of django and the Meta class defaulted to “managed = false”. For example:
class Rssemailsubscription(models.Model): id = models.CharField(primary_key=True, max_length=36) ... area = models.FloatField('Area (Sq. KM)', null=True) class Meta: managed = False db_table="RSSEmailSubscription"
makemigrations started picking up changes.
Method : 1
Step : 1
Make sure your app must be included in
INSTALLED_APPS in settings.py
Stpe : 2
python manage.py makemigrations <appname>
if same message shows (No changes detected)
!Warning This is Very Risky For Your Project So Make Sure You Have Backup For Your Project Before Applying The Method 2.
rename your app name and make new app using :
django-admin startapp <appname>
except from the old app
- migration folder
- pycache folder
- test.py file if you didn’t wrote code in it
and paste into the new app which you made recently
remember you have to make exact the same name for new app otherwise you have to make more changes in the project.
Another possible reason is if you had some models defined in another file (not in a package) and haven’t referenced that anywhere else.
For me, simply adding
from .graph_model import * to
graph_model.py was the new file) fixed the problem.
This might hopefully help someone else, as I ended up spending hours trying to chase this down.
If you have a function within your model by the same name, this will remove the value. Pretty obvious in hindsight, but nonetheless.
So, if you have something like this:
class Foobar(models.Model): [...] something = models.BooleanField(default=False) [...] def something(self): return [some logic]
In that case, the function will override the setting above, making it “invisible” to
A very dumb issue you can have as well is to define two
class Meta in your model. In that case, any change to the first one won’t be applied when running
class Product(models.Model): somefield = models.CharField(max_length=255) someotherfield = models.CharField(max_length=255) class Meta: indexes = [models.Index(fields=["somefield"], name="somefield_idx")] def somefunc(self): pass # Many lines... class Meta: indexes = [models.Index(fields=["someotherfield"], name="someotherfield_idx")]
When adding new models to the django api application and running the
python manage.py makemigrations the tool did not detect any new models.
The strange thing was that the old models did got picked by
makemigrations, but this was because they were referenced in the
urlpatterns chain and the tool somehow detected them. So keep an eye on that behavior.
The problem was because the directory structure corresponding to the models package had subpackages and all the
__init__.py files were empty. They must explicitly import all the required classes in each subfolder and in the models
__init__.py for Django to pick them up with the
models ├── __init__.py <--- empty ├── patient │ ├── __init__.py <--- empty │ ├── breed.py │ └── ... ├── timeline │ ├── __init__.py <-- empty │ ├── event.py │ └── ...
I had a different issue while creating a new app called
deals. I wanted to separate the models inside that app so I had 2 model files named
python manage.py makemigrations I got:
No changes detected.
I went ahead and inside the
__init__.py which lives on the same directory where my model files lived (deals and dealer) I did
from .deals import * from .dealers import *
And then the
makemigrations command worked.
Turns out that if you are not importing the models anywhere OR your models file name isn’t
models.py then the models wont be detected.
Another issue that happened to me is the way I wrote the app in
It should’ve been including the root project folder:
I solved that problem by doing this:
- Erase the “db.sqlite3” file. The issue here is that your current data base will be erased, so you will have to remake it again.
- Inside the migrations folder of your edited app, erase the last updated file. Remember that the first created file is: “0001_initial.py”. For example: I made a new class and register it by the “makemigrations” and “migrate” procedure, now a new file called “0002_auto_etc.py” was created; erase it.
- Go to the “pycache” folder (inside the migrations folder) and erase the file “0002_auto_etc.pyc”.
- Finally, go to the console and use “python manage.py makemigrations” and “python manage.py migrate”.
I know this is an old question but I fought with this same issue all day and my solution was a simple one.
I had my directory structure something along the lines of…
apps/ app/ __init__.py app_sub1/ __init__.py models.py app_sub2/ __init__.py models.py app_sub3/ __init__.py models.py app2/ __init__.py app2_sub1/ __init__.py models.py app2_sub2/ __init__.py models.py app2_sub3/ __init__.py models.py main_app/ __init__.py models.py
And since all the other models up until the one I had a problem with were being imported somewhere else that ended up importing from
main_app which was registered in the
INSTALLED_APPS, I just got lucky that they all worked.
But since I only added each
INSTALLED_APPS and not the
app_sub* when I finally added a new models file that wasn’t imported ANYWHERE else, Django totally ignored it.
My fix was adding a
models.py file to the base directory of each
app like this…
apps/ app/ __init__.py models.py <<<<<<<<<<-------------------------- app_sub1/ __init__.py models.py app_sub2/ __init__.py models.py app_sub3/ __init__.py models.py app2/ __init__.py models.py <<<<<<<<<<-------------------------- app2_sub1/ __init__.py models.py app2_sub2/ __init__.py models.py app2_sub3/ __init__.py models.py main_app/ __init__.py models.py
and then add
from apps.app.app_sub1 import * and so on to each of the
Bleh… this took me SO long to figure out and I couldn’t find the solution anywhere… I even went to page 2 of the google results.
Hope this helps someone!
I forgot to put correct arguments:
class LineInOffice(models.Model): # here addressOfOffice = models.CharField("Корхоная жош",max_length= 200) #and here ...
and then it started to drop that annoying
No changes detected in app ‘myApp ‘
In my case i forgot to insert the class arguments
INSTALLED_APPS = [ 'blog.apps.BlogConfig', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', ]
make sure ‘blog.apps.BlogConfig’, (this is included in your settings.py in order to make your app migrations)
then run python3 manage.py makemigrations blog or your app name
The solution is you have to include your app in INSTALLED_APPS.
I missed it and I found this same issue.
after specifying my app name migration became successful
INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'boards', ]
please note I mentioned boards in last, which is my app name.
One more edge case and solution:
I added a boolean field, and at the same time added an @property referencing it, with the same name (doh). Commented the property and migration sees and adds the new field. Renamed the property and all is good.
I had a similar issue with django 3.0, according migrations section in the official documentation, running this was enough to update my table structure:
python manage.py makemigrations python manage.py migrate
But the output was always the same: ‘no change detected’ about my models after I executed ‘makemigrations’ script.
I had a syntax error on models.py at the model I wanted to update on db:
field_model : models.CharField(max_length=255, ...)
field_model = models.CharField(max_length=255, ...)
Solving this stupid mistake, with those command the migration was done without problems. Maybe this helps someone.
This could be done by using two steps that are mentioned below.
- add your app to
- open admin.py
from .models import upImg # Register your models here. admin.site.register(upImg)
upImg with your className defined in
after that see if there still any
python manage.py makemigrations are left or not. if there is, than execute
python manage.py migrate too.
For more info follow this django tutorial.
You should add
The possible reason could be deletion of the existing db file and migrations folder
you can use python
manage.py makemigrations <app_name> this should work. I once faced a similar problem.
If you have the
managed = True in yout model Meta, you need to remove it and do a migration. Then run the migrations again, it will detect the new updates.
Try registering your model in admin.py, here’s an example:-
You can do the following things:-
1. admin.site.register(YourModelHere) # In admin.py
2. Reload the page and try again
3. Hit CTRL-S and save
4. There might be an error, specially check models.py and admin.py
5. Or, at the end of it all just restart the server
My problem with this error, was that I had included:
class Meta: abstract = True
Inside model that I wanted to creation migrate for.