#35424: Migration autodetector fails when order_with_respect_to is removed, but an _order field remains ------------------------------------+-------------------------------------- Reporter: Stuart Attenborrow | Owner: nobody Type: Bug | Status: closed Component: Migrations | Version: 4.2 Severity: Normal | Resolution: needsinfo Keywords: | Triage Stage: Unreviewed Has patch: 0 | Needs documentation: 0 Needs tests: 0 | Patch needs improvement: 0 Easy pickings: 1 | UI/UX: 0 ------------------------------------+-------------------------------------- Comment (by Stuart Attenborrow):
Thanks for looking into it. Due to the error you're seeing, the migrations had to be staggered to achieve the changes. e.g.: - [https://github.com/stuarta0/django-order-with-respect- to/blob/main/mysite/polls/migrations/0002_alter_choice_order_with_respect_to.py 0002_alter_choice_order_with_respect_to]: arranging the test. - [https://github.com/stuarta0/django-order-with-respect- to/blob/main/mysite/polls/migrations/0003_choice_order.py 0003_choice_order]: we wanted to move to our own ordering, but retain the data from the existing hidden field. Removing order_with_respect_to would've lost the data, so we added a placeholder field to store the result, and copied the values across with a simple python migration. - [https://github.com/stuarta0/django-order-with-respect- to/blob/main/mysite/polls/migrations/0004_alter_choice_options_and_more.py 0004_alter_choice_options_and_more]: the order_with_respect_to field can be removed, which drops the hidden column. - [https://github.com/stuarta0/django-order-with-respect- to/blob/main/mysite/polls/migrations/0005_alter_choice_options_rename_order_choice__order.py 0005_alter_choice_options_rename_order_choice__order]: finally, we can rename our placeholder field. Since the code is 8 years old and written by another author, I can't give you an explicit reason why the "_order" name was reused other than my assumption that "order" is a reserved word and "_order" was good enough for django internals at the time. However, it hasn't been an issue because django never had code that was structured in the way it is now. The answer for new projects is probably to remake or squash migrations to avoid it, but it's quite difficult on a legacy project with this scale of migrations. My suggested change in the original report fixes the issue for this case, but I haven't run django tests to see if it fails in other cases. -- Ticket URL: <https://code.djangoproject.com/ticket/35424#comment:3> Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines. -- You received this message because you are subscribed to the Google Groups "Django updates" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-updates+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/0107018f4b411483-93edd662-e371-4083-8f94-b66ef89e4b47-000000%40eu-central-1.amazonses.com.