Opened 2 years ago
Closed 2 years ago
#33710 closed Bug (fixed)
RenameIndex() crashes when unnamed index is moving backward and forward.
Reported by: | Mariusz Felisiak | Owned by: | David Wobrock |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Release blocker | Keywords: | |
Cc: | David Wobrock | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
RenameIndex()
should restore the old auto-generated name when an unnamed index for unique_together
is moving backward. Now re-applying RenameIndex()
crashes. For example:
-
tests/migrations/test_operations.py
diff --git a/tests/migrations/test_operations.py b/tests/migrations/test_operations.py index cfd28b1b39..c0a55023bb 100644
a b class OperationTests(OperationTestBase): 2988 2988 with connection.schema_editor() as editor, self.assertNumQueries(0): 2989 2989 operation.database_backwards(app_label, editor, new_state, project_state) 2990 2990 self.assertIndexNameExists(table_name, "new_pony_test_idx") 2991 # Re-apply renaming. 2992 with connection.schema_editor() as editor: 2993 operation.database_forwards(app_label, editor, project_state, new_state) 2994 self.assertIndexNameExists(table_name, "new_pony_test_idx") 2991 2995 # Deconstruction. 2992 2996 definition = operation.deconstruct() 2993 2997 self.assertEqual(definition[0], "RenameIndex")
crashes on PostgreSQL:
django.db.utils.ProgrammingError: relation "new_pony_test_idx" already exists
Change History (5)
follow-up: 2 comment:1 by , 2 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 2 years ago
Replying to David Wobrock:
I understand the issue that arises when one reverses a
RenameIndex
, but it was made "on purpose" somehow.
In https://code.djangoproject.com/ticket/27064,
For backwards operations with unnamed old indexes, RenameIndex is a noop.
From my understanding, when an unnamed index becomes "named", the idea was that it remained "named" even when reversing the operation.
Yes, sorry, I should predict that this is going to cause naming issues.
I guess the implementation is not entirely correct, since it doesn't allow idempotency of the operation when applying/un-applying it.
I'll try to find a fix
We should be able to find the old name with SchemaEditor._create_index_name()
.
follow-up: 4 comment:3 by , 2 years ago
I think making the database operation a noop when the old index has the same name as the new index name can be enough.
Here is a first draft https://github.com/django/django/pull/15695
comment:4 by , 2 years ago
Has patch: | set |
---|---|
Triage Stage: | Unreviewed → Ready for checkin |
Replying to David Wobrock:
I think making the database operation a noop when the old index has the same name as the new index name can be enough.
Here is a first draft https://github.com/django/django/pull/15695
Agreed.
I understand the issue that arises when one reverses a
RenameIndex
, but it was made "on purpose" somehow.In https://code.djangoproject.com/ticket/27064,
From my understanding, when an unnamed index becomes "named", the idea was that it remained "named" even when reversing the operation.
I guess the implementation is not entirely correct, since it doesn't allow idempotency of the operation when applying/un-applying it.
I'll try to find a fix