True, not the end of the world. Just ... another dependency. The NPM world
has traumatized me. Many thanks for creating that.
If there's nothing that can be done, it's time to move on. But worth
asking.
(Interestingly, even with the deprecation, historical migration fields
still need to be
I just say it: The decision certainly had good intentions, but maybe wasn't
fully informed. It happens.
But since we don't really have a processed to revert a deprecation, I would
recommend using the django-citext package. It's a drop-in replacement with
the same license as Django and a corporate
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
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
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
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
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
> 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
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
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
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
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
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
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
Hi there,
I am sorry that I missed this in the alpha. But to the best of my
knowledge, CITEXT and non-deterministic collations are not the same. They
don't support the same operations and their string comparison operations
are similar, yet not identical.
Furthermore, PostgreSQL doesn't
As far as I'm aware you can use:
CreateCollation("case_insensitive", "und-u-ks-level2", provider="icu",
deterministic=False)
to create a case insensitive collation on PostgreSQL.
--
You received this message because you are subscribed to the Google Groups
"Django developers
Since these are PotsgreSQL-specific fields that are being deprecated, might
it make sense to provide a hint as to what the CreateCollation() call
should be?
I'm looking around and it's not immediately obvious. The CreateCollation()
examples in Django are for a German phone book, where in
https://code.djangoproject.com/ticket/33872
--
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
> Support for PostgreSQL 10 was dropped in Django 4.1, and support for
PostgreSQL 11 was dropped in Django 4.2.
When CICharField, CIEmailField, CITextField deprecation starts in Django
4.2 they will be removed in Django 5.1.
--
You received this message because you are subscribed to the
wtorek, 25 stycznia 2022 o 13:59:54 UTC+1 Adam Johnson napisał(a):
> My initial concern was around the minimum PostgreSQL version that Django
> 5.0 will support. According to
> https://en.wikipedia.org/wiki/PostgreSQL#Release_history , PostgreSQL 10
> is supported until 2022-11-10 , and
Hi,
I'm not too sure about this.
While Postgres encourages using non-deterministic collations, they're not
without their downsides. For example, you can't do a LIKE query on a field
using a non-deterministic collation, but you can with CItext - although I
don't believe there's a way to index it.
Hi Mariusz,
I agree with you on deprecating and then removing CI fields.
I only would suggest adding some examples of migrations from CI fields
to collations in the deprecation notes to help users to easily
migrate.
So +1 for me too.
Ciao,
Paolo
On Tue, Jan 25, 2022 at 1:39 PM Mariusz
My initial concern was around the minimum PostgreSQL version that Django
5.0 will support. According to
https://en.wikipedia.org/wiki/PostgreSQL#Release_history , PostgreSQL 10 is
supported until 2022-11-10 , and version 11 until 2023-11-09. With Django
5.0 expected in 2024-01, it should be fine
Hi y'all,
Django 3.2+ supports "db_collation" [1] for "CharField" and
"TextField" along with migration operations ("CreateCollation()",
"RemoveCollation") and the database function "Collate()" [3]. Moreover
CI fields and the entire "citext" module are discouraged since
PostgreSQL 12 [4]
24 matches
Mail list logo
