Closed flbraun closed 5 years ago
blueyed
commented
5 years ago Thanks for the report. Are you sure this not just happened during the migration (which it was still running)?
But you might be right that we should not have changed 0003 maybe. The idea was to avoid running it in the first place - since this can be very slow.
Do you think squashing them would work?
mozz100
commented
5 years ago This affected us, too - and we also fortunately caught it in staging before it got to production.
Please don't rewrite migrations in released versions!
We followed the same steps as Chiron1991 to fix it. Could you publish a new version on pypi which doesn't include the modification to 0003, and remove 1.6.1, since anyone who upgrades from 1.6.0. to 1.6.1 will hit this issue?
blueyed
commented
5 years ago Sorry for the trouble! Please review https://github.com/gizmag/django-fsm-log/pull/89.
flbraun
commented
5 years ago Hm, this should do the trick. As @mozz100 said, please make a 1.6.2 release on PyPI as soon as possible.
I just encountered the following error after upgrading from 1.6.0 to 1.6.1 when running a transition:
This should not have happened, because the description field was made nullable in migration 0005 added in PR #84.
You also added the field alteration to migration 0003. AFAIK, since I already had this migration applied from a previous version of django-fsm-log, Django skipped the AlterField action in 0005 because it thought the removal of the not-null constrained had already been applied in 0003.
Fortunately I encountered this in a testing environment, manually rolling back to 0002 and forwarding to 0005 again fixed the issue. This would NOT have been a suitable solution in a production due to data loss and would require manual database manipulation.