I'm still pretty new to Python as well as Django so I have a situation I'm not sure how to resolve.
Main issue is that on deploy of my code to dev, deployment fails, to stage or prod, it passes.
I worked on an issue where I had to drop some columns in a table in our app. After making the changes, I deployed to dev and asked for a code review. In code review, it was suggested I change the name of the migration file to something more descriptive rather than just leaving it 0018_auto_.
I made that change and deployed to dev and stage. Dev failed (when I expected it to succeed) because the new name was seen and django tried to drop columns that no longer exist. In stage, the name was never changed and the columns were dropped for the first time using that new name of the file.
So stage deploys just fine.
How do I resolve this error on dev so it recognizes this migration already took place?
Thanks!
If you are 100% sure that the only change done for 0018 was the file name, and that it is the last migration for your app, you can do:
python manage.py migrate myapp 0017 --fake # Move to 17 without removing changes done by 18
python manage.py migrate myapp 0018 --fake # 18 is already applied, so just migrate with the new filename
This will keep the changes that are present in 0018, and just apply the changes to the filename.
Django constructs a table named djang_migrations that keeps track of the migrations that have been applied. If you later change the name of a migration file, then it will appear as if that migration did not run.
You can rename the migration in the django_migrations table of your development environment with:
UPDATE django_migrations
SET name = '0018_new_name'
WHERE app = '%%%name_of_the_app'
AND name = '0018_auto_'where 0018_new_name is the new name of the migration file.
By updating this name, Django should now consider the new migration file as done.
All these were great answers and will no doubt help others now and in the future!
I tried all these answers but only one thing worked. The long way!
For full visibility (this worked locally and I understand --fake now in practice, thanks @brian-destura!):
python manage.py migrate myapp 0017 --fake # Move to 17 without removing changes done by 18
python manage.py migrate myapp 0018 --fake # 18 is already applied, so just migrate with the new filename
In deployment through gitlab, our django / zappa app just didn't want to deploy successfully though (even with many different solutions tried).
In the end, the only way to fix the issue was to update the 0018 migration file to add back all those fields, rollback the changes in the models and serializers, and re-deploy to dev.
After that, revert all those changes including the migration file, and re-deploy again to dev.
There's probably some easier way to do this but with all those with more backend knowledge out for the holidays (I'm a front end originally with more backend knowledge/projects through the last year), I was very happy to resolve and release my changes.
Thanks to you guys for some things to try, ideas, and def knowledge I could use to create this, my own long winded solution!