#28646: Migration calls "CREATE INDEX" when one already exists when 'unique'
field
attribute is added (PostgreSQL)
-------------------------------------+-------------------------------------
Reporter: Hari - 何瑞理 | Owner: (none)
Type: Bug | Status: new
Component: Migrations | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
postgresql,migration,index,#djangocph|
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Ihor Marhitych):
Hello,
I started looking into this issue during the Django sprints at EuroPython
2025. It turned out to be more complex than I initially expected, but I’ve
now had time to complete my investigation.
From what I can see, the current logic is correct, and no fix is needed.
The proposed failing test above isn't valid, as it runs all three
operations within a single context manager. This causes index
removal/creation to be deferred, as described in the Django schema editor
documentation:
https://docs.djangoproject.com/en/5.2/ref/schema-editor/
"It must be used via the context manager as this allows it to manage
things like transactions and deferred SQL (like creating ForeignKey
constraints)."
In the failing case(test), when converting from a unique to a non-unique
field, the `_like` index should be first dropped in
`super()._alter_field`, then later recreated. However, because index
removal is deferred within the context manager, the creation step fails
(since the index still exists at that point).
When I run each of the three operations in separate context managers, the
test passes as expected. This also explains why the issue cannot be
reproduced in a live environment.
The logic around creating the _like index can be a bit confusing, but it's
closely tied to index removal logic here:
https://github.com/django/django/blob/main/django/db/backends/base/schema.py#L1021
While digging into this behavior, I wrote a few additional tests and added
inline comments to help clarify the flow. You can find the changes in my
fork:
https://github.com/django/django/commit/8539cfb5270661e803c9a0f0d7313ef60d8070a6
If those tests and comments are seen helpful, I’d be happy to open PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/28646#comment:34>
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 visit
https://groups.google.com/d/msgid/django-updates/01070199012fdc5e-cb3d24b4-39e4-48a0-bda1-ea2ad102e234-000000%40eu-central-1.amazonses.com.
