RenameIndex() crashes when unnamed index is moving backward and forward.

[Mariusz Felisiak]

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

@@ -2988 +2988 @@
         with connection.schema_editor() as editor, self.assertNumQueries(0):
             operation.database_backwards(app_label, editor, new_state, project_state)
         self.assertIndexNameExists(table_name, "new_pony_test_idx")
+        # Re-apply renaming.
+        with connection.schema_editor() as editor:
+            operation.database_forwards(app_label, editor, project_state, new_state)
+        self.assertIndexNameExists(table_name, "new_pony_test_idx")
         # Deconstruction.
         definition = operation.deconstruct()
         self.assertEqual(definition[0], "RenameIndex")

crashes on PostgreSQL:

django.db.utils.ProgrammingError: relation "new_pony_test_idx" already exists

[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.
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

[Mariusz Felisiak]

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().

[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

[Mariusz Felisiak]

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.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 11310e9a:

Fixed #33710 -- Made RenameIndex operation a noop when the old and new name match.