2016-10-25

geekchick77: (Default)
2016-10-25 11:35 am

Django migrations - when squashmigrations fails

I am working on a large app (hundreds of migrations) and it is becoming unwieldy. There are options for not running migrations when unit testing, but it'd be nice not to need to use them. Plus some of the old migrations reference old code I'd like to be able to delete.

I tried running squashmigrations, but the resulting migration file had errors when I tried to run it on a clean DB.

So, I decided to do the more drastic method of deleting and recreating migrations.

WARNINGS:
  1. ALL databases must be at the same migration level before you begin.
  2. If you have a custom user model, do NOT delete the migration that creates it. You can safely delete subsequent migrations.
  3. If you have data migrations, you need to maintain those.

Procedure for app that contains the custom user (e.g. if app name is "users"):
  1. Ensure all databases (local, staging, production, etc.) are at the same migration level.
  2. Create backups of all your databases.
  3. Save the code for any data migrations in a temporary file.
  4. Delete migration files from 0002 upward (assuming 0001 created the custom user) and commit to git
  5. delete from django_migrations where app='users' and name NOT LIKE '0001%';
  6. python manage.py makemigrations users
  7. Recreate any data migrations.
  8. Verify that migrations run successfully on a clean database.
  9. python manage.py migrate users --fake # Run locally
  10. Commit new migrations.
  11. Push changes to all other systems and on each run: python manage.py migrate users --fake

Procedure for apps in general (e.g. "myapp"):
  1. Ensure all databases (local, staging, production, etc.) are at the same migration level.
  2. Create backups of all your databases.
  3. Save the code for any data migrations in a temporary file.
  4. Delete migration files for myapp and commit to git.
  5. delete from django_migrations where app='myapp';
  6. python manage.py makemigrations myapp
  7. Recreate any data migrations.
  8. Verify that migrations run successfully on a clean database
  9. python manage.py migrate myapp --fake # Run locally
  10. Commit new migrations.
  11. Push changes to all other systems and on each run: python manage.py migrate myapp --fake
geekchick77: (Default)
2016-10-25 12:56 pm

PyCharm features: local history

You know that moment where you had working code, and now it has stopped working, and you aren't quite sure what you've changed? You made a lot of good changes since your last commit, and you don't want to throw those away, but you need to find the erroneous change. This is where PyCharm's local history functionality really shines. You can right click (or ctrl-click) on a file or a workspace, and see a timeline of all changes, with a visual diff of each change. This can help you quickly hunt down errors, without throwing away your good changes. It's particularly helpful if you're experimented with many different variations for a specific block of code.


Example screenshot