#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 [email protected].
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.
