Migration hell again. Here's what happened:

Converted a CharField into a ForeignKey field. I get errors from postgres saying the char can't be cast to an integer. Problem is, I didn't get this error on my development machine, only on the box I'm trying to deploy to. When I try to migrate backwards on my development machine so that I can tweak the migration, I get a similar error on the backward migration on a different column. One that was a ForeignKey field and is now a Char Field.

The fix for the backwards migration was to add two manual sql migrations. The first one to allow nulling fields, and the second to null the fields. Then there's no issue moving from a char field to a foreign key. This does mess with the null constraint. Hopefully that won't bite me.

Django migrations and branching

I got myself in to django migration hell this week. Here's how.

Working on my main branch, then switched to a feature branch created by a co-worker (we'll call him Barnaby). The feature branch had some model changes, and some migrations. I ran those migrations, and viewed the feature branch.

Then I switched back to my main branch. I got errors because the database no longer matched my models. I tried (without thinking it through) to migrate backwards. This didn't work, becuase the migrations that had gotten me in to this state were no longer present. I then made the mistake of manually updating my database to its pre-migration state.

This put me in a situation where when I tried to re-run the migration, after merging in Barnaby's code, it didn't want to run, because the migration was recorded in the django_migrations table. I tried deleting the migration entry and got myself in to more trouble, with this error:

django.db.utils.ProgrammingError: relation "signage_scheduleentry_0dee419f" already exists

I don't know how deep this rabbit hole will go, so am just restoring my development database from a backup.