django-treebeard: Model change in 4.5 may produce unexpected migrations in downstream projects
As documented at https://github.com/wagtail/wagtail/issues/6820, this model-level change means that upgrading to django-treebeard 4.5 will generate a new migration on models extending MP_Node. This has caused a bit of a maintenance headache for Wagtail, and I suspect that other downstream packages depending on treebeard may encounter similar issues:
- Wagtail has a dependency on
django-treebeard<5.0, and contains aPagemodel in one of its own apps that extends MP_Node - Someone with an existing wagtail project performs a routine
pip install, installing treebeard 4.5 - The next time they run
./manage.py makemigrations, it creates an00xx_auto_yyyymmddmigration inside the wagtail package (which will typically be somewhere in site_packages and not easily accessible to non-expert developers) - Failure case 1: the developer continues making model changes in their project, creating migrations that reference the phantom
00xx_auto_yyyymmddmigration in their dependencies. On deploying these changes to production, the migrations fail because this migration does not exist on the live server’s installation of wagtail. - Failure case 2: the developer upgrades their development instance to the next version of wagtail, replacing the previously installed package that had the
00xx_auto_yyyymmddmigration in it. Any subsequent migrations then fail, because the00xx_auto_yyyymmddis part of their migration history but no longer exists.
For now, we’ve dealt with this by making a patch release of wagtail that pins treebeard to <4.5, and in the next feature release we’ll ship the necessary migration in the wagtail package along with bumping treebeard to >=4.5,<4.6. However, relying on a narrow dependency range has its own problems, particularly if projects rely on multiple third-party packages that depend on treebeard.
This is probably more a consequence of the Django migration framework’s design rather than anything treebeard is doing wrong - it’s just that with treebeard being something that’s likely to be fairly deep in dependency chains, migrations have unusually large consequences, even ones like this that don’t make any schema-level changes. Perhaps it makes sense to adopt a policy of only making migration-requiring changes in major releases?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 3
- Comments: 15 (12 by maintainers)
Commits related to this issue
- Reverting unnecesary default in mp depth field Solves #211 — committed to django-treebeard/django-treebeard by tabo 3 years ago
@ababic That is true, but by having the beta or an rc version first, one is strongly signaling that this is a commit that one should try out. I would not normally test just any random commit on a dependent package.
If the model change can indeed be rolled back without breaking the intent of #192, then I’m also in favour of doing that in a 4.6 (or 4.5.1) release. From Wagtail’s perspective, that means that someone upgrading directly from 4.4 to 4.6 will avoid the issue, and we can set a dependency on
django-treebeard>=4.2.0,<5.0,!=4.5in the next release.And for any projects (Wagtail or not) where people don’t skip 4.5 and experience problems due to the migrations, I can’t think of any reason why the second migration would cause any new problems that aren’t already present (other than @ababic having to update his fix-up instructions to cover a possible second migration 😃 )
@gasman Thanks for the report. I filed #212 to prevent this from happening again, and would appreciate your input there.
As for this ticket this comment may be relevant:
I would like to explore this solution so we could revert the change triggering migrations ASAP.