[Django] #25694: Migrate command creates a default index for a CharField with a wrong '_uniq' suffix in the name
Django
'_uniq' suffix in the name
-------------------------------+--------------------
Reporter: synasius | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
This issue relates to #25412.
You can reproduce the error using this sample project:
[https://github.com/synasius/foo]
Checkout the project and run `./manage.py sqlmigrate bar 0002`.
You should see something like
`CREATE INDEX "bar_car_name_32db83d8bfa014c3_uniq" ON "bar_car" ("name");`
--
Ticket URL: <https://code.djangoproject.com/ticket/25694>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* needs_docs: => 0
* needs_better_patch: => 0
* type: Uncategorized => Bug
* needs_tests: => 0
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:1>
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by varunnaganathan):
I came across 2 points:
1.The error occurs on all databases except an sqlite3 one.
2.If db_index=True in the first initial migration, _uniq is not
suffixed.Whenever it is later being added in another migration _uniq is
appended.
Now,database indexes have to be unique in the table.Maybe since we are
later altering the field , the _uniq has to be appended?
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:2>
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jdufresne):
* cc: jon.dufresne@… (added)
* has_patch: 0 => 1
Comment:
https://github.com/django/django/pull/6834
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:3>
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MarkusH):
* needs_better_patch: 0 => 1
Comment:
How do you suggest to take care of existing indexes that would now need to
be renamed?
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:4>
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by jdufresne):
> How do you suggest to take care of existing indexes that would now need
to be renamed?
Is this a required component of this bug fix?
With the current implementation, migrations don't actually care about the
name of the index. It is just for human aesthetics. When removing an
index, Django will remove all non-unique indexes regardless of the name. I
actually bumped into this while working on another ticket and thought it
would be a quick fix.
If this is required, maybe there could be something like
`Field.index_name_version` that could be inspected during migrations. If
the version has changed, drop and recreate indexes. Then in the upgrade
docs, recommend people run `makemigrations` after updating. Thoughts on
this approach?
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:5>
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by MarkusH):
Replying to [comment:5 jdufresne]:
> > How do you suggest to take care of existing indexes that would now
need to be renamed?
>
> Is this a required component of this bug fix?
Yes. If we suddenly end up with either 2 indexes on a field applications
become slow. And, if not handled correctly, when we have 2 indexes on a
field and only drop 1 we might not be able to drop the field given a stale
index.
> With the current implementation, migrations don't actually care about
the name of the index. It is just for human aesthetics. When removing an
index, Django will remove all non-unique indexes regardless of the name. I
actually bumped into this while working on another ticket and thought it
would be a quick fix.
So, you're saying Django already dropps all indexes on a field. Good. That
makes the proposal redundant.
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:6>
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by jdufresne):
> So, you're saying Django already dropps all indexes on a field. Good.
That makes the proposal redundant.
Yes, it drops all indexes when there is a change in field's `db_index`
state. A link to the code:
Notice it loops over all indexes, instead of looking them up by name. The
comment "no strict check, as multiple indexes are possible" even suggests
this is intentional.
However, if there is no change to the field's state, the indexes will not
be dropped/recreated. So upgrading to the next Django version will leave
some of the old names with `_uniq` around until the field's state changes.
This is why I proposed the "version" idea. That could be recognized as a
change in state.
With this new understanding, is no action acceptable? Can I unset "Patch
needs improvement"? Or should I got ahead with the "version" proposal?
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:7>
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jdufresne):
* needs_better_patch: 1 => 0
Comment:
> Good. That makes the proposal redundant.
Ok thanks. Then I will proceed.
I have updated the test to work with Oracle.
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:8>
Django
'_uniq' suffix in the name
Reporter: synasius | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.8
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"16614dcd5cad50648ef75021b919fc90dd449312" 16614dc]:
{{{
#!CommitTicketReference repository=""
revision="16614dcd5cad50648ef75021b919fc90dd449312"
Fixed #25694 -- Removed incorrect _uniq suffix on index names during
migrations.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25694#comment:9>