It was less code/effort than researching all the available ones out
there as I knew what I wanted to accomplish.
Since doing this, haven't had enough "pain level" to look at some of
the other solutions.
Unlike you, Trey, I prefer to write the migrations in SQL instead of
Python for a couple of reasons. The primary of these reasons is that
not all migrations are simple DDL changes. Sometimes there is the need
to fix or otherwise manipulate data well, and it just feels as if you
get a lot more control when writing in a language that the database
understands.
If you ever think you are going to move to MySql just use it from the
get-go. You could be setting yourself up for some pain later on.
./manage.py dmigrate autogenerateThat spits out a few migrations, maybe one for each table that is changing in some way.
Probably as often as people revert code in a source code repository
rather than just plugging away to fix a mistake. It good to have the
functionality in case something really bad happens, though.