Changes between Initial Version and Version 1 of Ticket #28646


Ignore:
Timestamp:
Sep 27, 2017, 9:52:36 PM (7 years ago)
Author:
Hari - 何瑞理
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #28646 – Description

    initial v1  
    1 PostgreSQL migration automatically creates an index for fields that set db_index=True. An example is SlugField, which sets this property implicitly. Thereafter when the unique=True property is added to the field the resultant migration script generates an AlterField object to apply this unique attribute. The schema editor then incorrectly detects this new unique=True attribute to indicate the need to create a like index statement on the field which causes an error as it conflicts with the already existing index.
     1PostgreSQL migration automatically creates an index for fields that set `db_index=True`. An example is `SlugField`, which sets this property implicitly. Thereafter when the `unique=True` property is added to the field the resultant migration script generates an AlterField object to apply this unique attribute. The schema editor then incorrectly detects this new `unique=True` attribute to indicate the need to create a like index statement on the field which causes an error as it conflicts with the already existing index.
    22
    33The offending piece of code seems to be at django/db/backends/postgresql/schema.py:117.
    … …  
    2121this error won't occur.
    2222
    23 PostgreSQL 9.5 introduces 'IF NOT EXISTS' to the CREATE INDEX statement which if added to the schema template can also address this problem without changing the above logic.
     23PostgreSQL 9.5 introduces `IF NOT EXISTS` to the `CREATE INDEX` statement which if added to the schema template can also address this problem without changing the above logic.
    2424
    25 I encountered the problem with SlugField() which implicitly sets db_index = True on PostgreSQL 9.4.
     25I encountered the problem with `SlugField()` which implicitly sets `db_index=True` on PostgreSQL 9.4.
    2626
    27 Interestingly, I only discovered this when I used django-tenant-schemas which adds a thin layer on top of the default Database router setting the schema search path before handing over the work to the default router. With a vanilla Django installation using default router, the second call to create a like index does not throw an error. However, upon reviewing the code, the logic does look incorrect.
     27Interestingly, I only discovered this when I used `django-tenant-schemas` which adds a thin layer on top of the default Database router setting the schema search path before handing over the work to the default router. With a vanilla Django installation using default router, the second call to create a like index does not throw an error. However, upon reviewing the code, the logic does look incorrect. Also issuing the duplicate SQL statement in PostgreSQL console also throws an error.
    2828
    2929I'm still investigating to see if this there's more to this than what I just described.
Back to Top