CODEWITHSUNDEEP
djangodjango-migrations
Escher
Escher

Reputation: 5766

makemigrations doesn't detect changes in model

I'm using django 1.9.6. I recently deleted my migrations and ran migrate --run-syncdb and makemigrations my_app. Today I added a new field to one of my models:

models.py:

value = models.PositiveSmallIntegerField(null=True)

I tried to migrate the changes, but makemigrations doesn't detect the change. It's just the development version, so I can resync (I don't have to preserve the data), but running --run-syncdb again doesn't detect it either.

Why isn't this migrating?

Upvotes: 24

Views: 34772

Answers (9)

Hemant Sagar
Hemant Sagar

Reputation: 11

In my case makemigrations wasn't detecting changes in models. However "python manage.py migrate --run-syncdb" worked. But it wasn't permanent solution for every change I make. So I created new project with same name, apps with same names. Copied files from old project folder to the new one. Now makemigrations is working as expected. Only drawback is that db.sqlite3 was reacreated. I used DBBrowser to copy some data I needed from old db.sqlite3 to new one.

Upvotes: 0

CSS-Romeo
CSS-Romeo

Reputation: 362

In my case, the settings.py file was missing the app in which I created the new models. After declaring the app in the INSTALLED_APPS list in settings.py file, the command python manage.py makemigrations works as expected.

Upvotes: 1

dotcomly
dotcomly

Reputation: 2214

You should not delete migrations, you should squash them. If you simply deleted the files you likely messed things up, the easiest way to recover is re-sync your code to get the files back. A more complex route is to delete all the records from the django_migrations table and re-init the migrations from scratch but there is more steps/issues than I can really get into and I don't recommend it.

The reason makemigrations is not detecting the change is likely because there is no migrations folder in that app. If you run python manage.py makemigrations your_app --initial it might detect and generate the migrations or it might freak out because of the difference in your files and the django_migrations table.

The --run-syncdb command is great when you don't care about the data, usually before you actually deploy but once you start using migrations you should not use the --run-syncdb command anymore. For instance, during initial development here is the code I run every model change instead of dealing with migrations:

dropdb mydb && createdb mydb && python manage.py migrate --run-syncdb && python manage.py loaddata initial

I store all the initial data in a fixtures file and the command wipes out the entire database, the --run-syncdb rebuilds the schema, and the initial data is loaded while skipping actual migration files.

So, if you don't care about any of your data or can easily move it to a fixture than you can drop and re-create the DB. You are then free to delete all migration folders and you can use the command above until you go live and need to move to using migrations.

*** UPDATE FOR DJANGO 1.11 *** STILL USING ON 3.2.5 ***

I started using Django 1.11 and noticed the test framework can fail if you have dependencies on framework models and don't actually have migrations. This is the new command i'm using to wipe everything out and start over while still developing.

set -e
dropdb yourdb
createdb yourdb
find . -name "migrations" -type d -prune -exec rm -rf {} \;
python manage.py makemigrations name every app you use seperated by space
python manage.py migrate
python manage.py loaddata initial

I put this in a builddb.sh at the root of my project (next to manage.py) so I can just run ./builddb.sh. Be sure to delete it on deploy so there is no accidents!

Upvotes: 18

Kundan Kumar
Kundan Kumar

Reputation: 511

In my case, I created a new project and created an app. The python manage.py makemigrations returned no change detected although I had added a handful of models. Found out that you need to manually add the name of your app in the INSTALLED_APPS list inside your settings.py file. Unless you do that, no change in the migration of that app can be detected.

Upvotes: 3

Eduard Mukans
Eduard Mukans

Reputation: 1015

Another case is abstract classes. Make sure that your model’s metaclass does not have the abstract = True property.

Upvotes: 0

Roshan Maharjan
Roshan Maharjan

Reputation: 302

Try creating a migrations folder that contains an empty __init__.py file inside your app folder if there is no migrations folder already. And make migrations.

Upvotes: 17

cdosborn
cdosborn

Reputation: 3449

If you're deleting a model, and expecting the changes to be picked up in migrations, ensure that the model doesn't have a *.pyc still lying around.

Upvotes: 0

Liyosi
Liyosi

Reputation: 609

I had the same issue. I realised I had a property defined on the model with the same name as a field I was trying to add on the model. Ensure the model doesn't have a model property/method with the same name as the field you are trying to add.

Upvotes: 22

Kristian
Kristian

Reputation: 756

Delete every past migration files and __pycache__ files except __init__ then:

python manage.py makemigrations yourApp

After that make sure that the db is the same as the code in model.py (remove new changes) and run next line:

python manage.py migrate --fake-initial

Now add all your changes in the model.py and run next lines:

python manage.py makemigrations 
python manage.py migrate

Best Regards, Kristian

Upvotes: 24

Related Questions