Hello again, I trust Mariusz' assessment regarding the maintainability. In that case, I presume a separate package from a 3rd party with commercial interest might be the best option going forward.
Thanks for all the considerations and explanations. Cheers! Joe On Wed, Apr 19, 2023 at 3:48 PM fly.a...@gmail.com <fly.amur...@gmail.com> wrote: > Hey everyone! > > Thanks for the discussion. > And special thanks @Adam, for the great article, helped us with the > migration. > > 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 feature > deprecation (and the docs does not mention this case). > Good that Adam covered it in the article, but I feel that this could be > handled on a lower level than right now. Currently, we'd need to write a > manual annotation for admin queryset in almost every project that uses > usernames or emails (which my guess is something you'd want to be > case-insensitive on a database level). > > I wonder how we could move forward (in case reverting this is not an > option) and reduce overall aftermath stress. > For example, in terms of documentation, we could add a note on > `db_collation` to `icontains` page: > https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains > > But I also feel that might not be enough. > > Best, > Rust > > > On Tuesday, 18 April 2023 at 09:52:20 UTC+2 Johannes Maron wrote: > >> Thanks Adam, >> >> of course I read your well-written article before diving into this topic, >> thanks for sharing. >> >> However, I don't agree about the index. The best solution is using the >> CITEXT db type, which is very much alive. >> Should Django to deprecate support for the db type, a 3rd party package >> seems the bast choice for me. >> With the downside of me having to maintain yet another package. But I can >> understand if the Django project has no interest in maintenance. >> >> In any event, I opened a ticket: >> https://code.djangoproject.com/ticket/34501 >> >> Best Joe >> >> >> On Fri, Apr 14, 2023 at 11:36 AM 'Adam Johnson' via Django developers >> (Contributions to Django itself) <django-d...@googlegroups.com> wrote: >> >>> Just to note, for anyone that finds it useful, that I wrote a blog post >>> on migrating to collations: >>> https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/ >>> >>> But yes, I have also been thinking like Tom that indexing UPPER("email") >>> seems to be the path of least complexity... >>> >>> On Thu, Apr 13, 2023 at 8:12 AM Tom Carrick <t...@carrick.eu> wrote: >>> >>>> Hi, >>>> >>>> I wrote most of the code for collation support, and I also argued >>>> (softly) against deprecating citext support for the reasons you stated. >>>> >>>> However, I've changed my mind on this now. 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 actually think the >>>> best practice right now for having searchable case-insensitive emails is to >>>> do it old-school - have a regular EmailField with an index on >>>> UPPER("email") and then make sure you always use iexact, istartswith etc. >>>> and this will properly use the indexes and result in a faster search. >>>> >>>> So I see very few advantages now to keeping CITEXT at all, and they're >>>> quite easy to add as a third party package as Mariusz suggested if anyone >>>> is so inclined. >>>> >>>> Cheers, >>>> Tom >>>> >>>> On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak <felisiak...@gmail.com> >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> > Unless we want to drop support for the CITEXT extension, ... >>>>> >>>>> What do you mean by that? As far as I'm now, we don't do anything >>>>> special to support CITEXT extension 🤔. >>>>> >>>>> > I'd caution to revert the deprecation and keep support ... >>>>> >>>>> I'm obviously biased as the author of this proposition and patch, >>>>> however, IMO, small differences between using CI fields and collations >>>>> don't justify maintaining 3 additional fields that were mostly untested. >>>>> Also, they are deprecated in a LTS so folks still have *3* more years >>>>> to update their code. In the worst case someone can create 3rd party >>>>> package with them. >>>>> >>>>> Unless something is fundamentally broken I'm against reverting. >>>>> >>>>> Best, >>>>> Mariusz >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Django developers (Contributions to Django itself)" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to django-develop...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/django-developers/5c11b704-68c4-490d-84bf-90c734cc02d1n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/django-developers/5c11b704-68c4-490d-84bf-90c734cc02d1n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers (Contributions to Django itself)" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to django-develop...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/CAHoz%3DMb25iGN%2BHodxgE6Y%2B5d%2B5qoHERvkMiuiHrs%3DXnpeC%3D-xg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMb25iGN%2BHodxgE6Y%2B5d%2B5qoHERvkMiuiHrs%3DXnpeC%3D-xg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> >> You received this message because you are subscribed to a topic in the >>> Google Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/django-developers/nDMnO98nexY/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> django-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/CAMyDDM3PuF92jEdTocGPtG%2Bq0n%2B%3DfRfZ05gTw8w3T6kZ5p6xBQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CAMyDDM3PuF92jEdTocGPtG%2Bq0n%2B%3DfRfZ05gTw8w3T6kZ5p6xBQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/nDMnO98nexY/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/5108100c-2967-4a8e-9840-59d187f895cdn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/5108100c-2967-4a8e-9840-59d187f895cdn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPcC2o%3DWPmKDxCD5zZHwJs5jB3XEXzBZh79qnDYdSD85T1Y3wQ%40mail.gmail.com.
