[Django] #28053: Allow fields to specify arbitrary indexes via db_index=Index()
Django
-------------------------------------+-------------------------------------
Reporter: Marc | Owner: nobody
Tamlyn |
Type: | Status: new
Uncategorized |
Component: Database | Version: 1.11
layer (models, ORM) |
Severity: Normal | Keywords: indexes migrations
Triage Stage: | Has patch: 1
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 1 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Expand `Field.db_index` to allow explicitly setting an index.
Syntax would look something like:
`HStoreField(db_index=GinIndex())`
Changes needed:
- Indexes won't necessarily receive fields initially.
- Fields are responsible for their own indexes. This is tackled here and
has implications for #27859, `_like` indexes on Postgres, and other
situations where we customise the indexes. It is possible, but I'm not
sure, that `Field.get_indexes()` could also handle unique conditions, but
I think it's better kept separately as not all databases consider
uniqueness to be an index.
- Change to `SchemaEditor.alter_field` so it receives the `to_model`, so
that the `Index` can resolve the correct column names. This is extra
important for `db_index` being a functional index (see #26167), although
that's not currently supported in the current data.
--
Ticket URL: <https://code.djangoproject.com/ticket/28053>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: Uncategorized | Status: new
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution:
Keywords: indexes migrations | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_docs: 0 => 1
* needs_tests: 0 => 1
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:1>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution:
Keywords: indexes migrations | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Uncategorized => New feature
Comment:
WIP [https://github.com/django/django/pull/8322 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:2>
Django
-------------------------------------+-------------------------------------
| Sarıgöl
Type: New feature | Status: assigned
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution:
Keywords: indexes migrations | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => assigned
* needs_better_patch: 1 => 0
* owner: nobody => Can Sarıgöl
Comment:
new WP [https://github.com/django/django/pull/11264 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:3>
Django
-------------------------------------+-------------------------------------
| Sarıgöl
Type: New feature | Status: assigned
(models, ORM) |
Severity: Normal | Resolution:
Keywords: indexes migrations | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
* version: 1.11 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:4>
Django
-------------------------------------+-------------------------------------
| Sarıgöl
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_docs: 1 => 0
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:5>
Django
-------------------------------------+-------------------------------------
| Sarıgöl
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:6>
Django
-------------------------------------+-------------------------------------
| Sarıgöl
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Markus Holtermann):
I had a chat with felixxm discussing the usefulness of this feature.
The initial idea behind this feature, as far as I can reconstruct from
memory, came from the requirement that I wanted to have a custom index on
a field by default, because I didn't want to tell users to add a specific
index to `Meta.indexes`. The naïve approach Marc and I agreed upon back in
the days was about this:
* A field has a `default_index_class` or `default_index`
property/attribute or whatnot. When a field has `db_index=True`, this
index definition would be used.
* Now, a custom field that would want to require an index, could reject
`db_index` as an argument in `__init__` and set it to `True` all the time.
* A user could, however, may would like to be able to make adjustments to
the index that's defined by the field. Thus, passing their own index
definition in place of `db_index` (and not have the field reject the
argument.
This change would also allow to dynamically construct an index based on
the other arguments passed to `__ini__`:
{{{#!python
class MyField(CharField):
def __init__(self, arg1: str, arg2: int, **kwargs):
db_index = kwargs.pop("db_index", None)
if db_index is None:
db_index = MyIndexClass(arg1, math.pi * arg2)
super().__init__(db_index=db_index, **kwargs)
class MyModel(models.Model):
field1 = MyField()
field2 = MyField(db_index=Index(name="foo"))
}}}
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:7>
Django
-------------------------------------+-------------------------------------
| Sarıgöl
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Can Sarıgöl):
Hi, thanks for your detailed explanation. Firstly, I wanted to be sure to
understand you. Because of that I've issued a
[https://github.com/django/django/pull/11264/commits/9d27856794e0d4e50212e5a55285cd324f09fb5d
commit]. I'm using {{{_get_index_type_kwargs}}} to getting kwargs for
{{{_create_index_sql}}}. I applied it in this part. what do you think?
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:8>
Django
-------------------------------------+-------------------------------------
| Pandey
Type: New feature | Status: assigned
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: Can Sarıgöl => Aman Pandey
--
Ticket URL: <https://code.djangoproject.com/ticket/28053#comment:9>