Sat morning #Django thought:
Could migrations be improved if we store a hash of the migration file itself in the django_migrations table to help identify when a person changes a migration file after it's been applied?
Sat morning #Django thought:
Could migrations be improved if we store a hash of the migration file itself in the django_migrations table to help identify when a person changes a migration file after it's been applied?
@CodenameTim What situations are you thinking of where a migration file is accidentally changed and not caught by diff/PR review? I don't exclude migrations from linters and frequently backfill no-op migration changes to previous files. For example, changing help_text or choice values.
@mike The case I'm thinking of is before a commit is made. And probably in an environment where there isn't a code review process (a beginner). It's also be helpful when a person applies a migration, deletes the file, then recreates one that's similar but has a difference that's not reflected in the filename but is potentially problematic.