The reason I opened all the problems in a single ticket was to show the
disadvantages of the "UPPER" function used in the "icontains" operator.I
think that instead of using "UPPER (column) like" used in the Django ORM
filter method, the "icontains" operator should use the "ilike" operator and
this
Unless I’m missing something, the ticket you linked was last updated 7
years ago with two now-broken images. Which ticket did you open with the
examples?
Tom
On Sun, 28 Feb 2021 at 08:31, Mesut Öncel wrote:
> The reason I opened all the problems in a single ticket was to show the
> disadvantage
Yes, 7 years ago I reviewed the ticket for the updated code, but there are
problems there.https: //code.djangoproject.com/ticket/32485 The ticket I
opened has the necessary details. If you want more details, I can make the
necessary explanations.
Tom Forbes , 28 Şub 2021 Paz, 12:36 tarihinde şunu
Thank you for the clarification!
On Sun, 28 Feb 2021 at 09:23, Mesut Öncel wrote:
> Yes, 7 years ago I reviewed the ticket for the updated code, but there are
> problems there.https: //code.djangoproject.com/ticket/32485 The ticket I
> opened has the necessary details. If you want more details,
Thank you for the clarification! I think the biggest argument for this
change is the fact that uppercasing Unicode can cause incorrect results to
be returned.
Given that we now have much better support for custom index types, perhaps
we should change this? We need a custom expression index anyway,
You're welcome. Yes, database administrators can create an index as
desired. However, creating multiple cin indexes in a single column with
different methods will cause performance issues. I don't think using
expressions when using like and ilike is a correct use for query
performance.
It doesn't h
A discussion was requested from here to make changes on this issue. Do you
think it would be appropriate if I open a pull request for this change?
Mesut Öncel , 28 Şub 2021 Paz, 14:06 tarihinde şunu
yazdı:
> You're welcome. Yes, database administrators can create an index as
> desired. However, c
Guys, am noob anyone gonna guide?
On Sun, Feb 28, 2021, 11:39 AM Tom Forbes wrote:
> Thank you for the clarification! I think the biggest argument for this
> change is the fact that uppercasing Unicode can cause incorrect results to
> be returned.
>
> Given that we now have much better support f
The ticket I posted in the first email does not belong to me. The ticket I
opened is https://code.djangoproject.com/ticket/32485.
Sky Lord , 28 Şub 2021 Paz, 14:59 tarihinde şunu
yazdı:
> Guys, am noob anyone gonna guide?
>
> On Sun, Feb 28, 2021, 11:39 AM Tom Forbes wrote:
>
>> Thank you for th
Hi all.
Calendar Week 5 -- ending 07 February.
Triaged:
https://code.djangoproject.com/ticket/32411 -- JSONField filter icontains
is case sensitive in mysql (Invalid)
https://code.djangoproject.com/ticket/32409 -- TestCase async tests are not
transaction-aware (Accepted)
https://code.django
On Sun, Feb 28, 2021 at 2:39 AM Tom Forbes wrote:
>
> Thank you for the clarification! I think the biggest argument for this change
> is the fact that uppercasing Unicode can cause incorrect results to be
> returned.
>
> Given that we now have much better support for custom index types, perhaps
Hi James,
Thanks for your explanations. However, I wanted to explain the disadvantage
of using "UPPER like" instead of "ilike" in icontains, istartswith and
iendswith. The performance problem should not be ignored.
James Bennett , 1 Mar 2021 Pzt, 04:05 tarihinde şunu
yazdı:
> On Sun, Feb 28, 202
12 matches
Mail list logo
