Everything works fine but when I execute “migrate” as a manage.py command, it always says “Your models in app(s): ‘admin’, ‘auth’, ‘base’, ‘contenttypes’, ‘sessions’ have changes that are not yet reflected in a migration, and so won’t be applied.
Run ‘manage.py makemigrations’ to make new migrations, and then re-run ‘manage.py migrate’ to apply them.”
If I execute “makemigrations” commands I always get “No changes detected”.
I downgrade to Django2, the message is gone.
I have every mentioned app on my INSTALLED_APPS variable in settings. As you can see only ‘base’ app is one of mine, the rest are default Django apps.
I am using Oracle 19 database that can not be recreated.
I hope you can help me or give me some ideas of what is happening and why am I receiving that message from “migrate” command.
I have the same type of issue with current Django 4.1.4!
The makemigrations command reports “no changes detected” which is as expected. Running migrate gives me the infamous “Your models in … have changes that are not yet reflected in a migration, and so won’t be applied.” message.
I think it’s strange that two commands that are supposed to work hand in hand disagree on the existence of changes. Don’t they use the same code for this? Also, is there a way to make the migrate command display the reasons for its complaint?
The most common reason I’ve seen for makemigrations not recognizing differences between models and tables is that the app doesn’t have a migrations directory.
Side note: The two commands makemigrations and migrate really do perform two completely different operations. Yes, migrate uses the output of makemigrations as input - but there are other ways of creating migration files as well. (e.g. See Migrations | Django documentation | Django)
…and thank you for your feedback. All my migration directories are alive and well. So this can’t be the cause.
Some more info: I have around 10 apps in my django folder and the problem only affects one of them. I haven’t done any changes to that apps models lately which is why I wonder why this problem occurs now. I just updated to Django 4.1.4, maybe that’s a clue?
BTW, if I deliberately change the model, makemigrations does its job and so does migrate without any complaints. When I run “manage.py migrate” again, I immediately receive the error mentioned above. I think, this is a rather strange behavior, so could this maybe be a bug in the migrate script? I was hoping that migrate and makemigrations use the same code to discover changes but that does not seem to be the case…
I would suggest using the sqlmigrate command on that last working migration to see the SQL being generated for that migration - and then checking the database to verify that those operations were actually performed.
While it’s possible that there’s a bug in migrate, I’m more inclined to believe the problem is going to either be a permissions issue with the database to where the user account being used doesn’t have permissions to perform the necessary operation, or an issue with the Oracle backend, or some type of version incompatibility in one of the libraries along the line.
Aside from upgrading Django, you’ll want to ensure that other required libraries are up-to-date as well.
Thanks again, this is a good idea indeed. Just checked the last 3 migrations against the database. They seem to have performed correctly and added the requested fields. As said before, I didn’t modify the models anyway apart from the deliberate changes I made to test the migration scripts…
I just made some copies of the migrate and makemigrations commands and added some debug output. Migrate is indeed getting a new migration (last number + 1) from autodetector.changes() while makemigrations isn’t.
I had the same issue but found the solution, and since googling for it led me here first, here’s what worked for me.
I place all my models in a models folder with an __init__.py file inside, and then I separate models with one file for each model. I simply forgot to import the new models in the __init__.py file.
So let’s say you have models/A.py containing the model A, you need to add from .A import A in your models/__init__.py file
This happened to me recently. The problem for me was that I had as a default value for a uuid field ‘uuid.uuid4()’ and that caused to be evaluated every time I was running the migrate command and having a different value each time which caused to appear as having not migrated changes
Just checked the last 3 migrations against the database. They seem to have performed correctly and added the requested fields. As said before, I didn’t modify the models anyway apart from the deliberate changes I made to test the migration scripts…