Re: Deprecate CICharField, CIEmailField, CITextField

['Adam Johnson' via Django developers (Contributions to Django itself)]

> 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).
>

Yes, I discovered this too. It's what prompted me to write the parametrized
admin tests covered in my later blog post:
https://adamj.eu/tech/2023/03/17/django-parameterized-tests-model-admin-classes/

Annotating appropriately is what I found to work.

Tom Carrick wrote earlier:

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.
>

I also think this may be a better approach, now. But I haven't tried it.

Django 5.0 will hopefully come with generated fields:
https://github.com/django/django/pull/16417 . We may then be able to store
the user-provided email in "email_original_cased" (or whatever) and make
"email" a GeneratedField(expression=Lower("email")), with the lowercase
collation and a unique consrtaint. We'll have to see...


> 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


That sounds like too specific a note to add. Many different data types in
many different databases fail to work with some existing lookups, such as
several custom fields in Django-MySQL:
https://django-mysql.readthedocs.io/en/latest/model_fields/index.html


On Sat, May 6, 2023 at 9:50 AM 'Johannes Maron' via Django developers
(Contributions to Django itself)  wrote:

> 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 
> 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)  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

Re: Ticket #34555 ModelBase prevents addition of model Fields via __init_subclass__

['Adam Johnson' via Django developers (Contributions to Django itself)]

+1 from me. As Simon covered on the ticket, the change is small. Making
Django classes support __init_subclass__ might unlock some nice dynamic
field patterns.

On Thu, May 11, 2023 at 12:47 PM hottwaj 
wrote:

> Hi there, I opened the above ticket and submitted a PR with fix and test
> added.  I was asked to bring the issue here for wider review before the
> ticket is re-opened (if that is what people agree to do)
>
> For reference, links to the ticket and PR are:
> https://code.djangoproject.com/ticket/34555
> https://github.com/django/django/pull/16849
>
> The issue raised is that current implementation of ModelBase.__new__
> prevents use of __init_subclass__ on a Model to add model fields
>
> e.g. the code listed at the end of this email does not currently work (the
> PR fixes this).
>
> Currently the same result could be achieved by i) writing a new metaclass
> e.g. BaseBookModelMeta or ii) using a class decorator where
> cls.add_to_class(field) is called.
>
> Using __init_subclass__ is advised as a simpler alternative to writing a
> metaclass to customise class creation, hence this PR.
>
> Hope that makes sense and appreciate any feedback.  Thanks!
>
>
> class BaseBookModel(models.Model):
> class Meta:
> abstract = True
>
> def __init_subclass__(cls, author_cls, **kwargs):
> super().__init_subclass__(**kwargs)
> cls.author = models.ForeignKey(author_cls,
> on_delete=models.CASCADE)
>
> class Author(models.Model):
> name = models.CharField(max_length=256, unique=True)
>
> class Book(BaseBookModel, author_cls=Author):
> pass
>
> --
> 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/015a5798-d084-4afb-b800-e83154301ec7n%40googlegroups.com
> 
> .
>

-- 
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/CAMyDDM2OojqTe5r_SBiWcVAgOLSZHNcdwg9qvLBT%2BBOpxR2yyg%40mail.gmail.com.

Re: Conclusion of ticket #26761

['Adam Johnson' via Django developers (Contributions to Django itself)]

I have replied on the ticket with an example using arbitrary HTML as
required.

On Wed, May 10, 2023 at 10:30 AM Carsten Fuchs 
wrote:

> Hello,
>
> ticket #26761 was closed as wontfix, however I don't understand the reason.
> https://code.djangoproject.com/ticket/26761#comment:19
>
> The ticket's author asked to add a help_text-like attribute for read-only
> fields that are specified via functions. The intention was for it to work
> analogously to the help_text attribute of model fields.
>
> For such an attribute, there are two places that it might affect:
>
>   - the list page (where the help_text of a model field is available as a
> tooltip over a "(?)" mark in the column header)
>
>   - the change object page (where the help_text of a model field is
> available as a message below the field's value)
>
> Please see that attached image for an example.
>
> Unfortunately, Mariusz closed the ticket with the argument that
> `short_description` could be used in place of `help_text`. However, to the
> best of my understanding, that is not right: `short_description` changes
> the *label* of the fields (in the screenshot "Lokaler Zeitpunkt" and
> "Bewertung"), but not the text below the values.
>
> May this be reconsidered?
>
> Best regards,
> Carsten
>
> --
> 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/8e72c318-f28d-465f-8707-47e77a5d0d20%40cafu.de
> .
>

-- 
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/CAMyDDM1Ha2vj_ZM7KmCHd4bSF1GpzKxDYtuFMRHdg5xwq_grmg%40mail.gmail.com.

Re: Deprecate CICharField, CIEmailField, CITextField

['Johannes Maron' via Django developers (Contributions to Django itself)]

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 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).
>>
>
> Yes, I discovered this too. It's what prompted me to write the
> parametrized admin tests covered in my later blog post:
> https://adamj.eu/tech/2023/03/17/django-parameterized-tests-model-admin-classes/
>
> Annotating appropriately is what I found to work.
>
> Tom Carrick wrote earlier:
>
> 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.
>>
>
> I also think this may be a better approach, now. But I haven't tried it.
>
> Django 5.0 will hopefully come with generated fields:
> https://github.com/django/django/pull/16417 . We may then be able to
> store the user-provided email in "email_original_cased" (or whatever) and
> make "email" a GeneratedField(expression=Lower("email")), with the
> lowercase collation and a unique consrtaint. We'll have to see...
>
>
>> 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
>
>
> That sounds like too specific a note to add. Many different data types in
> many different databases fail to work with some existing lookups, such as
> several custom fields in Django-MySQL:
> https://django-mysql.readthedocs.io/en/latest/model_fields/index.html
>
>
> On Sat, May 6, 2023 at 9:50 AM 'Johannes Maron' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> 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 
>> 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