A few comments:
- Unclear what exactly caused the migration to break, was it simply the is_clean field not getting set? Would this have been prevented with stricter column constraints on the db?
- The rollback failed to solve the problem. In my experience, rollbacks are often problematic and it's better to regard fixing a broken database chance as another migration ("forward" rather than "backward" if you will)
- The test code feels quite clumsy (for instance, having to load old state). The testing also feels less rigorous than directly checking the resulting schema matches the intended state. I'm an advocate of a diff-based approach that directly compares schemas at a database level (see: https://djrobstep.com/talks/your-migrations-are-bad-and-you-...). What do you think?
- Another advantage of not using django-style migrations, is that if you need to make urgent changes to solve a downtime issue (for instance, a quick "update" query), you can freely do that outside the concept of a prepared migration if necessary, without any need to go and add that history back into the migration chain later (because there is no history beyond current version and target version).
