{{{#!python
class MyModel(models.Model):
column = ArrayField(
CITextField(max_length=255),
)
class Meta:
indexes = [
GinIndex(fields=['column'], name='mygin')
]
}}}
Migration fails because:
{{{
django.db.utils.ProgrammingError: data type citext[] has no default
operator class for access method "gin"
HINT: You must specify an operator class for the index or define a
default operator class for the data type.
}}}
full trace on this
[https://gist.github.com/vad/7f0414b8a52bb288f64f6c1df6006b35 gist]. To
solve this issue an Operator Class
[http://stackoverflow.com/a/20102665/690696 must be created]
--
Ticket URL: <https://code.djangoproject.com/ticket/27437>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/27437#comment:1>
* owner: (none) => Mads Jensen
* status: new => assigned
Comment:
I have some code, tests, and documentation for this, although the SQL code
from Stackoverflow appears to be incorrect (I get
{{{django.db.utils.InternalError: ginqueryarrayextract: unknown strategy
number: 7}}}).
--
Ticket URL: <https://code.djangoproject.com/ticket/27437#comment:2>
Comment (by Mads Jensen):
[https://github.com/django/django/pull/7585 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/27437#comment:3>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27437#comment:4>
Comment (by Simon Charette):
As I mentioned to the reporter at DUTH I'm not convinced this a common
enough use case to ship and maintain a custom operation class.
I'd be in favor of moving the ticket to ''Someday/Maybe'' and see if this
gather any traction as both `GINIndex` and `CITextField` are new features
in the still unreleased Django 1.11.
--
Ticket URL: <https://code.djangoproject.com/ticket/27437#comment:5>
Comment (by Mads Jensen):
I'm a bit indifferent to how this will get treated.
--
Ticket URL: <https://code.djangoproject.com/ticket/27437#comment:6>
* stage: Accepted => Someday/Maybe
Comment:
Yes, this looks a bit specialized. In my opinion, `contrib.postgres`
should aim for implementing things that are an ~80% use case. As Simon
said, it would be nice to have more evidence that this is common before
committing to include it. Anyway, the code is on the pull request for
anyone who would like to use it in their own project.
--
Ticket URL: <https://code.djangoproject.com/ticket/27437#comment:7>
* status: assigned => closed
* resolution: => wontfix
Comment:
It's niche. Moreover the `citext`
extension[https://www.postgresql.org/docs/current/citext.html is
discouraged since PostgreSQL 12] in favor of
[https://www.postgresql.org/docs/current/collation.html non-deterministic
collations] that are supported in Django 3.2+ via the new `db_collation`
argument for `CharField` and `TextField`.
--
Ticket URL: <https://code.djangoproject.com/ticket/27437#comment:8>