Django - makemigrations - No changes detected

问题

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?

回答1:

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

回答2:

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

回答3:

There are multiple possible reasons for django not detecting what to migrate during the makemigrations command.

migration folder You need a migrations package in your app.
INSTALLED_APPS You need your app to be specified in the INSTALLED_APPS .dict
Verbosity start by running makemigrations -v 3 for verbosity. This might shed some light on the problem.
Full path In INSTALLED_APPS it 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_label in 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)

Multiple databases:

Db Router when working with django db router, the router class (your custom router class) needs to implement the allow_syncdb method.

makemigrations always creates migrations for model changes, but if allow_migrate() returns False,

回答4:

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 models.py, 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.

回答5:

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',
]

Then run:

./manage.py makemigrations blog

回答6:

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>

回答7:

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

回答8:

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'

By changing manged to True, makemigrations started picking up changes.

回答9:

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

回答10:

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.

回答11:

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

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

回答12:

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 app to 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 app level models.py files.

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!

回答13:

Make sure your app is mentioned in installed_apps in settings.py
Make sure you model class extends models.Model

回答14:

I forgot to put correct arguments:

class LineInOffice(models.Model):   # here
    addressOfOffice = models.CharField("Корхоная жош",max_length= 200)   #and here
    ...

in models.py and then it started to drop that annoying

No changes detected in app 'myApp '

回答15:

You should add polls.apps.PollsConfig to INSTALLED_APPS in setting.py

回答16:

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

回答17:

First of all, make sure your app is registered in the Installed_app in the setting.py Then the above answer works perfectly fine

回答18:

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 admin.py (where graph_model.py was the new file) fixed the problem.

回答19:

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

Whaat??

I had mistakenly also removed all the __init__.py files :( - Everything was working again after I went in and:

touch ads1/migrations/__init__.py

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.

回答20:

In my case i forgot to insert the class arguments

Wrong:

class AccountInformation():

Correct

class AccountInformation(models.Model):

回答21:

In my case, I first added a field to the model, and Django said there're no changes.

Than I decided to change the "table name" of the model, makemigrations worked. Than I changed table name back to default, and the new field was also there.

There is a "bug" in django migration system, sometimes it doesn't see the new field. Might be related with date field.

来源：https://stackoverflow.com/questions/36153748/django-makemigrations-no-changes-detected

标签

python

django

django-migrations