It's good to, as a minimum, specify noop
in RunPython
so the migration can be skipped when going backwards, and even better to specify a function that undoes the migration.
The code in forwards
mutates the data, but in order to undo the change then reverse_code
is needed.
If reverse_code
is missing then when an attempt is made to undo the migration then Django will raise IrreversibleError
.
This is a problem because it prevents rolling back the state of the database, which may be needed if a bug is detected after a production deployment and the last good version of the app needs deploying back to production. Without reverse_code
, the state of the database will be out of step with the app code.
If our GitHub code review bot spots this issue in your pull request it gives this advice:
1 | + | class Migration(migrations.Migration): | |
2 | + | dependencies = [("core", "0001_initial.py")] | |
3 | + | operations = [RunPython(forwards)] |
It's good to, as a minimum, specify noop
in RunPython
so the migration can be skipped when going backwards, and even better to specify a function that undoes the migration.
- | operations = [RunPython(forwards)] |
+ | operations = [RunPython(forwards, RunPython.noop)] |