How to reset migrations in Django 1.7
Solution 1
I would just do the following on both the environments (as long as the code is the same)
- Delete your migrations folder
- DELETE FROM django_migrations WHERE app =
<your app name>
. You could alternatively just truncate this table. python manage.py makemigrations
python manage.py migrate --fake
After this all your changes should get detected across environments.
Solution 2
Run
python manage.py migrate your_app zero
This will drop all tables from your_app
If you want, since you said you want to start over, you can delete your migrations folder, or maybe rename the folder, create a new migrations folder and run
python manage.py makemigrations your_app
python manage.py migrate your_app
Just like south, you can always go back and forth...
# Go to the first migration
python manage.py migrate your_app 0001
# Go to the third migration
python manage.py migrate your_app 0003
So imagine that your 4th migration is a mess... you can always migrate to the 3rd, remove the 4th migration file and do it again.
Note:
This one of the reasons your models should be in different apps. Say you have 2 models : User and Note. It's a good practice to create 2 apps: users and notes so the migrations are independent from each other.
Try not use a single application for all your models
Solution 3
A minor variation on harshil's answer:
$ manage.py migrate --fake <appname> zero
$ rm -rf migrations
$ manage.py makemigrations <appname>
$ manage.py migrate --fake <appname>
This will ...
- pretend to rollback all of your migrations without touching the actual tables in the app
- remove your existing migration scripts for the app
- create a new initial migration for the app
- fake a migration to the initial migration for the app
Solution 4
To reset all migrations and start all over, you can run the following:
1. Reset all migration
python manage.py migrate <app_name> zero
ℹ️ If this is causing you issues you can add the
--fake
flag to the end of the command.
2. Create the migration
python manage.py makemigrations <app_name>
ℹ️ Only do this step if you deleted or altered the migrations files
3. Migrate
python manage.py migrate <app_name>
⚠️ if you added the
--fake
command to step # 1 you will need to add--fake-initial
to the migrate command sopython manage.py migrate <app_name> --fake-initial
Solution 5
I had a similar issue to this but when testing some of these same solutions using python manage.py showmigrations
I noticed I got the same error.
Eventually I found this post which helped me realize I was overcomplicating things and essentially had two User models defined.
![wobbily_col](https://i.stack.imgur.com/YGjz2.jpg?s=256&g=1)
wobbily_col
Full Stack / Backend Software Engineer, usually data driven applications, but a bit of everything. I have used plenty of languages and databases and tools in my time, fan of Django framework at the moment. I am currently Tech lead which involves a bit more management and onboarding of new team members as well as having an overall vision going forward for our product.
Updated on July 05, 2022Comments
-
wobbily_col almost 2 years
(I know there is a title the same as this, but the question is different).
I have managed to get my development machine migrations and production migrations out of sync.
I have a Django app which was using South. I had my own workflow that worked fine (it probably wasn't the correct way to do things, but I had no problems with it).
Basically I have a script that copies the production database dump to my development machine. It also copied the migration files. That way the two were in synch, and I could run South commands as normal.
Now I have upgraded to 1.7, and started using migrations. When I use my previous workflow (copy database dump, and migration files from production), it is not detecting changes on my development machine.
I have read through the migrations document, and I see that the correct way to use it is to
- run "make migrations" and "migrate" on my development machine.
- run "migrate" on my devlopemnt machine to actually make the database changes
- Copy changes over, including migration files.
- run "migrate" on the production machine. (without the "makemigrations" step)
Anyway. It is all a mess now. I would like to "reset" my migrations and start from scratch, doing things properly from now on.
What do I need to do?
- Delete the contents of the migration table (on both machines)?
- Delete the contents of the migration folder? (Including the init.py file).
- Start the migrations as per the documentation for a new one.
Have I missed anything? Is there a reason why copying everything from production(database and migration files) doesn't detect any changes on my development machine afterwards
-
wobbily_col over 9 yearsDrop all tables, on my app? That is definitely not the solution am looking for. Or have I misunderstood your wording?
-
brunofitas over 9 yearsapp, not project... anyway, check my edit... zero will clear everything on the app, not the project, before 0001...
-
wobbily_col over 9 yearsThanks for the update. I have tried deleting the migrations folder, but none of the changes get detected after that.
-
brunofitas over 9 yearsdid you migrate back to zero before you did that?
-
wobbily_col over 9 yearsRan zero, and nothing is detected or changed.
-
brunofitas over 9 yearsI guess you're confusing project with app. You project has several apps. for example "auth" is one. "auth" has "auth_user" and "auth_group" tables, right? If you run "python manage.py migrate auth zero" all tables from the app "auth" will be removed from the database. The same happens with other apps. Imagine you have an app called "notes". this would have a Model Note. Migrating this app would create a table "notes_note". If you run "python manage.py migrate notes zero", the table "notes_note" will be removed, but all the rest stays. Do you have many apps, or every model in one app ?
-
brunofitas over 9 yearsLet us continue this discussion in chat.
-
wobbily_col over 9 yearsThis sounds more or less like what I did in the end. I tried deleting (well actually renaming the django_migrations table). Then I discovered some app migrations depended on others, so I repopulated those entries in the new django_migrations table.
-
Eric Ressler about 8 yearsI've seen so many answers to similar questions that make this more complicated than it needs to be. This is the way to do it. Clean and simple.
-
Turtles Are Cute about 8 yearsNow Django won't detect any new changes; ie adding a table. any ideas?
-
Phil Gyford over 7 yearsI did this but, like Turtles Are Cute, kept getting "No changes detected" (Django 1.10). The solution was to run
makemigrations
specifying the app. e.g.,python manage.py makemigrations polls
if your app is calledpolls
. -
victor n. almost 7 yearsthis one works for me. can you put
zero
before--fake
. that's how it worked for me. -
rrauenza almost 7 yearsI've updated it to the format that
-h
says:Usage: ./manage.py migrate [options] [app_label] [migration_name]
-
Abdallah Okasha almost 6 years
python manage.py flush --no-input
to avoid no action after typing yes to continue -
yukashima huksay over 5 yearsif you delete the directory you should either specify the app name or recreate the directory. (the migrations directory)
-
Austin not from Boston about 4 years@PhilGyford thank you very much Phil. I ran into the same problem until I found your comment
-
embe almost 3 yearsWill this work also if the current database differs from models.py? For example if a few extra fields has been added in models.py but not yet in the database
-
Muhammad Zubair over 2 yearsJust to add, if you want to see the changes in the database schema also. First, delete any tables created against the old migrations, and then
migrate
without the--fake
option. -
Al Mahdi about 2 yearsThis is the perfect answer.