Coming in again now that I've looked at upgrading.
@Adam: your post was useful. But can you actually say you prefer the new
approach?
But I'm going to be honest, this is a lot of hoops and gotchas. What did we
actually gain by deprecating this? I'm seeing maybe 15-20 lines of code
that will be removed? Maybe a touch of ideological purity?
Is it unheard of to cancel plans to deprecate this, since it's still in the
code base?
99% of the use case is for CIEmailField, and 99% of people want this to be
searchable, likely within nested models as Matthew is trying to do.
So we took something that worked really well and removed it. I just don't
see the gain.
I hope we can change your minds. This is the first deprecation in 15 years
of usage that I just can't get behind.
On Wednesday, December 20, 2023 at 1:16:01 PM UTC-5 Matthew Graham wrote:
> I only started trying to move to collations instead of citext recently,
> and it broke the regex validation as as non deterministic collation can't
> support regex validator, like what, why are we replacing something with an
> alternative that actually cant do the job as a replacement
>
> On Thu, 21 Dec 2023, 4:59 am gw...@fusionbox.com,
> wrote:
>
>> This breaks search_fields. I can annotate a deterministic collation for
>> simple fields. I don't understand why I have to do workarounds to get
>> builtin stuff to work.
>>
>> There's no workaround I can figure out across joins though. I have
>> `search_fields = ['owners__email']`. Using an annotated field
>> `owners__email_deterministic` fails: django.core.exceptions.FieldError:
>> Unsupported lookup 'email_deterministic' for ForeignKey or join on the
>> field not permitted.
>>
>> I don't understand why I have to do workarounds to get builtin stuff to
>> work.
>>
>> > As you can't index the citext column for LIKE queries, doing these
>> types of searches on any real amount of data is going to be too slow in
>> most cases.
>>
>> I have 100k users and want to search them in the admin. The unindexed
>> query takes 100ms, which is completely fine for this purpose.
>>
>> Also, you CAN index a citext column for LIKE queries with pg_trgm.
>>
>> On Wednesday, September 6, 2023 at 11:56:49 AM UTC-6 Johannes Maron wrote:
>>
>>> Hi again,
>>>
>>> We started creating a 3rd party django-citext package, to ensure future
>>> support of PotsgreSQL's CITEXT extension under a corporate funding.
>>> You can find the project here: https://github.com/voiio/django-citext
>>>
>>> While doing so, I noticed a couple of small things, where I'd love some
>>> clarification to know which way to go:
>>>
>>>1. Will the CITextExtension stay? It's currently not deprecated,
>>>it's super class implements array support.
>>>2. The documentation currently can be misleading. Would you consider
>>>proposals for some changes:
>>> - There is a note about performance considerations, yet I
>>> couldn't find any. There are some limitations, which rightfully need
>>> to be
>>> considered when using the citext extension.
>>> - The deprecation hint towards collations. However, as previously
>>> explained, they are by no means an equal replacement. Would you
>>> accept a
>>> reference to a named or unnamed 3rd party solution for future support
>>> of
>>> the citext extension.
>>>3. Finally, Django's admin or rather lookups, don't play
>>>particularly nice with collations. Something to consider in the
>>> deprecation
>>>process.
>>>
>>>
>>> I am happy to get some feedback, especially on the extension and array
>>> support, since we haven't implemented that yet.
>>> If you have any other pointers, feel free to leave an issue report.
>>>
>>> Thanks!
>>> Joe
>>>
>>>
>>> On Fri, May 12, 2023 at 5:19 PM Johannes Maron
>>> wrote:
>>>
Hi,
Yes, I hope Django will continue to expand expression support. I worked
so hard on the SQL compiler to facilitate those kinds of features.
Anyhow, since db collations are not an adequate replacement for CI
text, we will create an open-source backport of the CITEXT fields.
Once we are done, I will open a PR to alter the documentation, to point
towards this option. This should allow users to choose, and will probably
easy migration to Django 5 for some.
But first, I gotta play Tears of the Kindom….
Cheers!
Joe
On Fri, May 12, 2023 at 1:37 PM 'Adam Johnson' via Django developers
(Contributions to Django itself) wrote:
>
> What I am struggling now with is whenever I specify
>> `db_collation="case_insensitive"` on the field and this field is used in
>> `ModelAdmin.search_fields` - Django simply breaks (as it by default uses
>> `icontains` lookup).
>> That is quite unfortunate for the big projects, as I have to come up
>> with some generic solution to something that was not broken before this
>>
