Re: Ticket #34646 Ordering a Django admin column based on multiple model fields

[Fran Hrženjak]

The proposed patch adds very little extra API surface. Django admin in fact 
already support this, but for this arbitrary restriction in 
`get_ordering_field`. The patch just makes it possible to pass a list down 
to `get_queryset` method.

I would argue that this patch removes a special case in the API. Everywhere 
else (I think, pls correct me) devs can specify multiple fields for 
ordering. Except here. From a certain point of view, removing special cases 
means reducing API surface (:

The patch could be even simpler, IMHO: just keep the name 
`get_ordering_field`, for compatibility with existing code. It is easier to 
document that the method "now also takes a list", especially since in most 
cases it is still going to be given a single string.

Can power that be take another look at this issue?  

+1 with an extra "cmon" from me!

-- 
Fran


On Friday, April 26, 2024 at 7:10:36 PM UTC+2 Mubarak Alrashidi wrote:

Could you re-consider it please?
it is really important, and we need it.
I have started another project where I need to create a computed column 
(used_invitations / max_invitations)

Best regards

On Friday, June 23, 2023 at 10:39:51 AM UTC+3 Mubarak Alrashidi wrote:

I really hope the developers implement the patch.

On Monday, June 19, 2023 at 4:55:42 AM UTC+3 David Sanders wrote:

Sorry to clarify I intended to respond with "niche solution" not "nice 
solution" lol. I didn't realise the phone's autocomplete had done that.

On Monday, 19 June 2023 at 11:05:41 UTC+10 David Sanders wrote:

Mariusz is a developer, so that's at least 1 developer's opinion :)

Unless anybody else pipes up to counter this I'd consider it to be a nice 
solution.

On Monday, 19 June 2023 at 05:01:52 UTC+10 Mubarak Alrashidi wrote:

Can we at least know what the developers think about it?


On Sunday, June 11, 2023 at 1:28:58 AM UTC+3 Mubarak Alrashidi wrote:

Hello,

I posted this StackOverflow question 
<https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem 
<https://code.djangoproject.com/query?status=!closed=KommuSoft> tried 
to help by opening a ticket numbered #34646 
<https://code.djangoproject.com/ticket/34646>, and creating a patch for 
supporting the order by multiple fields in admin.display decorator.

But it got closed as a duplicate of #31975 
<https://code.djangoproject.com/ticket/31975> which was reported about 3 
years ago, and it got closed as wontfix by @Mariusz Felisiak 
<https://github.com/felixxm> because he said: *"We don't want to add 
unnecessary complexity to the API.".*

And I agree with what @Petr Dlouhý 
<https://code.djangoproject.com/query?status=!closed=PetrDlouhy>
 says: *"it is small modification of Django code and small increase in API 
complexity (which is consistent with the logic of other order fields, 
BTW)."**.*

The inconsistency is when somewhere we're able to order by multiple fields, 
and somewhere else we can't.

If we can order by multiple fields in the modelAdmin classes, why can't we 
do so in the admin.display decorator?

So, I do hope to reconsider implementing the patch 
<https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff>
 that @Willem Van Onsem 
<https://code.djangoproject.com/query?status=!closed=KommuSoft>
 created.

Thanks

-- 
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/3c43fafb-a6e4-408c-89ff-4e35ad1afac7n%40googlegroups.com.

Re: Ticket #34646 Ordering a Django admin column based on multiple model fields

[Mubarak Alrashidi]

Could you re-consider it please?
it is really important, and we need it.
I have started another project where I need to create a computed column 
(used_invitations / max_invitations)

Best regards

On Friday, June 23, 2023 at 10:39:51 AM UTC+3 Mubarak Alrashidi wrote:

> I really hope the developers implement the patch.
>
> On Monday, June 19, 2023 at 4:55:42 AM UTC+3 David Sanders wrote:
>
>> Sorry to clarify I intended to respond with "niche solution" not "nice 
>> solution" lol. I didn't realise the phone's autocomplete had done that.
>>
>> On Monday, 19 June 2023 at 11:05:41 UTC+10 David Sanders wrote:
>>
>>> Mariusz is a developer, so that's at least 1 developer's opinion :)
>>>
>>> Unless anybody else pipes up to counter this I'd consider it to be a 
>>> nice solution.
>>>
>>> On Monday, 19 June 2023 at 05:01:52 UTC+10 Mubarak Alrashidi wrote:
>>>
>>>> Can we at least know what the developers think about it?
>>>>
>>>>
>>>> On Sunday, June 11, 2023 at 1:28:58 AM UTC+3 Mubarak Alrashidi wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I posted this StackOverflow question 
>>>>> <https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem 
>>>>> <https://code.djangoproject.com/query?status=!closed=KommuSoft> 
>>>>> tried 
>>>>> to help by opening a ticket numbered #34646 
>>>>> <https://code.djangoproject.com/ticket/34646>, and creating a patch 
>>>>> for supporting the order by multiple fields in admin.display
>>>>>  decorator.
>>>>>
>>>>> But it got closed as a duplicate of #31975 
>>>>> <https://code.djangoproject.com/ticket/31975> which was reported 
>>>>> about 3 years ago, and it got closed as wontfix by @Mariusz Felisiak 
>>>>> <https://github.com/felixxm> because he said: *"We don't want to add 
>>>>> unnecessary complexity to the API.".*
>>>>>
>>>>> And I agree with what @Petr Dlouhý 
>>>>> <https://code.djangoproject.com/query?status=!closed=PetrDlouhy>
>>>>>  says: *"it is small modification of Django code and small increase 
>>>>> in API complexity (which is consistent with the logic of other order 
>>>>> fields, BTW)."**.*
>>>>>
>>>>> The inconsistency is when somewhere we're able to order by multiple 
>>>>> fields, and somewhere else we can't.
>>>>>
>>>>> If we can order by multiple fields in the modelAdmin classes, why 
>>>>> can't we do so in the admin.display decorator?
>>>>>
>>>>> So, I do hope to reconsider implementing the patch 
>>>>> <https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff>
>>>>>  that @Willem Van Onsem 
>>>>> <https://code.djangoproject.com/query?status=!closed=KommuSoft>
>>>>>  created.
>>>>>
>>>>> Thanks
>>>>>
>>>>

-- 
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/bf583159-7891-4cdd-a797-a7242e5122den%40googlegroups.com.

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[Bendegúz Csirmaz]

Hi!

I would be happy to make a contribution if a decision can be reached.

I'm in favor of making the Group model swappable with the AUTH_GROUP_MODEL 
setting, similar to the User model.

The ticket was marked as Someday/Maybe, I'm not sure why.
The customization of the Group model is necessary in any bigger project, 
and defining a secondary model doesn't always cut it (e.g. when nesting the 
Group model).

AUTH_GROUP_MODEL is consistent with the User model and addresses all 
customization concerns.

Yes, it's hard to swap the User model in production, and it will be hard to 
swap the Group model.
It's still better than hacking around Django 
(see: 
https://stackoverflow.com/questions/2181039/how-do-i-extend-the-django-group-model).

I opened a PR  to add this, it 
addresses the basic functionality.

Let me know!
On Friday 24 January 2020 at 16:57:17 UTC+8 Adam Johnson wrote:

> Exactly as you see, nothing is done in secret.
>
> On Fri, 24 Jan 2020 at 08:44, LBris  wrote:
>
>> Hi everyone.
>>
>>
>> What is the state of this discussion and its attached ticket ?
>>
>> -- 
>>
> 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/47517107-c5d2-4986-8845-087cba05e340%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Adam
>

-- 
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/103b9150-54b5-4cd4-b27b-1fd6db7e5f5en%40googlegroups.com.

Re: Should Django use Ada?

['Michael Lissner' via Django developers (Contributions to Django itself)]

Thanks for the replies everybody. A few thoughts

>From Adrián:

> You should probably be addressing urllib devs with this inquiry (e.g. 
such vuln is then probably in many other web frameworks)

I did that in 2021 when I found the issue with newlines in URLs. Python 
devs had the resources to fix the newlines but not to make urlparse 
spec/browser compliant. They had concerns about backwards compatibility 
(fair enough), and it seemed like they'd have to largely rewrite the 
library to do things properly b/c URLs are so nasty these days. I think 
they also felt like they couldn't keep up with the standard and that the 
language shouldn't try. Instead, they argued the usual thing: folks should 
use third party libraries that can be better and that can change more 
quickly (fair enough). 

Until Ada, I hadn't heard of better solutions, so I let it lay.

>From Jorg:

> the fact that django or an upstream lib decided to slightly deviate from 
the latest URL parsing spec incarnation does not make it vulnerable per se

>From Adam:

> On the contradictory standards, see the cURL maintainer’s post

I agree, Jorg, and thanks for the cURL reference, Adam. Specs aren't my 
target so much as "what browsers do," and wherever our URL parser diverges 
from what browsers do, we risk a redirect vulnerability. It's been a few 
years since I worked on this issue, but IIRC, this particular spec is 
actually well aligned with what browsers do, so they're essentially one and 
the same.

I understand the push back that we need proof of an issue here before we'd 
move forward with anything. WHATHG provides a test suite of nasty URLs 
. I guess what I 
should do is run that through urlparse and look for places where it fails. 
If, for example, it's possible to send a valid URL to urlparse and have it 
get the wrong (sub)domain name, we would consider that a vulnerability or 
at least an issue, right?

-

That's it for my substantive comments, but I want to reply to this too:

> But then add something about their time being too valuable to work on 
making it better. 

I don't know C, so I can't help much with the Python language, but I am 
here, where I have more expertise. You'll note that I offered to assign a 
paid developer to adding Ada to Django if we wanted to. That's me being 
busy with other priorities, but offering resources from my org. If that's 
not good enough, I don't know what is. 

Also, I'm not denigrating Python by saying it's maintained by volunteers — 
in my experience, it is.  The fact that Python doesn't have tons of 
resources is one of the reasons it was difficult to get this vulnerability 
fixed in the language itself. They did a minimal fix because a bigger one 
wasn't possible given the resources of those that work on the language (and 
concerns about backwards compat). 

Finally, you might also consider that I spent a lot of my time working on 
the vulnerability above, and that I contribute to other open source 
projects practically every day for the last decade. Point being: If you 
want to drive me away from contributing here, you're on your way, but I'm 
here trying to help, and I've got a record of doing so here and elsewhere 
in various ways.

Sorry to others here for the off topic response. Though I probably should, 
I can't let that kind of comment go in the Django discussion group.

Thank you all,

Mike

-- 
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/3f95d432-67ad-45bc-aec1-063e9b762ac7n%40googlegroups.com.

Re: Should Django use Ada?

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

I agree with Jörg. We need evidence of problems before we decide to act, and 
that those problems aren’t being addressed in Python. Forcing a new dependency 
on all users is not something we’d do lightly.

On the contradictory standards, see the cURL maintainer’s post: 
https://daniel.haxx.se/blog/2022/10/18/deviating-from-specs/ .

> Anyhow, just out of curiosity, wouldn't it be possible to use 
> functools.partial function to replace urllib.parse.urlparse with ada-python 
> in settings.py? Or make some kind of django extension that integrates this 
> other dependency?

It should always be possible to create and use custom classes that use ada, 
such as an alternative URL field.

On Mon, 1 Apr 2024, at 23:45, Jörg Breitbart wrote:
> You write:
> 
> "It could still be a vulnerability ... / It could fail to parse ... / 
> could decide it's invalid - This is all pretty bad..."
> 
> I agree - this indeed would be really bad, if it can be used in 
> malicious ways. But note that the fact that django or an upstream lib 
> decided to slightly deviate from the latest URL parsing spec incarnation 
> does not make it vulnerable per se. URL specs (or URI in general) used 
> to contradict itself across various RFCs, so there is some ground of 
> interpretation and which rules to follow in an implementation. Also 
> django has to maintain backwards compat to some degree, and introducing 
> a foreign c++ lib binding in its default installation is a very bold move.
> 
> Anything into this direction needs proper justification and not just 
> handwaving arguments (FUD?), unless there actually is a real 
> vulnerability with the current impl.
> 
> Cheers,
> Jörg
> 
> -- 
> 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/726fce28-2273-4672-8e00-f8619b95b0d9%40netzkolchose.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/d97f33e2-5ac5-4ee5-8850-8b8cda3dc8b0%40app.fastmail.com.

Re: Should Django use Ada?

[Adrián Salatino]

You should probably be addressing urllib devs with this inquiry (e.g. such
vuln is then probably in many other web frameworks). Anyhow, just out of
curiosity, wouldn't it be possible to use functools.partial function to
replace urllib.parse.urlparse with ada-python in settings.py? Or make some
kind of django extension that integrates this other dependency?

On Mon, Apr 1, 2024 at 10:37 PM 'Michael Lissner' via Django developers
(Contributions to Django itself)  wrote:

> Hi all,
>
> A few years ago, I reported a vulnerability in Django because Python
> wasn't parsing URLs containing tabs or newlines correctly. In this ticket,
> it was fixed in Python:
>
> https://bugs.python.org/issue43882
>
> But Python, being maintained mostly by volunteers, did the minimum needed
> work to fix the vulnerability without really fixing the urlparse library
> properly.
>
> This means that it's probably still possible to send a URL to django that
> urlparse doesn't know how to handle. When this happens:
>
> 1. It could still be a vulnerability.* If this is the case, Django could
> redirect people to domains where it shouldn't.
>
> 2. It could fail to parse the URL properly, leading to the wrong URL being
> provided to the user.
>
> 3. urlparse could decide it's an invalid URL even though it's not.
>
> This is all pretty bad, but there is some hope in the form of a tool
> called Ada, which aims to actually support URL parsing properly:
>
> Homepage: https://www.ada-url.com/
> Github (more useful, really): https://github.com/ada-url/ada
>
> It's written in C++, is used in Node and Cloudflare Workers. It has
> bindings for Python, Rust, R, and Go. It's licensed under MIT and Apache
> License 2.0. It's fuzzed by Google OSS Fuzzer, and it's much faster than
> urlparse.
>
> I'm curious: Would Django consider switching to this library? I'm not sure
> if I'll have time to do the work, but I can at least open an issue if it's
> a useful switch to make, and I might be able to assign a developer to it if
> this is something we want.
>
> Love to hear thoughts,
>
> Mike
>
>
> * I'm posting this publicly because this kind of vulnerability is really
> well known these days, and exists across most general-purpose languages.
> URLs are just very difficult to parse properly.
>
> --
> 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/f31bc17b-c0c5-4ce4--7d1ec3dfe90bn%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/CABKWZPkFZFnxSLfxVZT_%2B69Yfyem4ZALK-s7HOtUGXs5%2Bs7J4w%40mail.gmail.com.

Re: Should Django use Ada?

[Jörg Breitbart]

You write:

"It could still be a vulnerability ... / It could fail to parse ... / 
could decide it's invalid - This is all pretty bad..."


I agree - this indeed would be really bad, if it can be used in 
malicious ways. But note that the fact that django or an upstream lib 
decided to slightly deviate from the latest URL parsing spec incarnation 
does not make it vulnerable per se. URL specs (or URI in general) used 
to contradict itself across various RFCs, so there is some ground of 
interpretation and which rules to follow in an implementation. Also 
django has to maintain backwards compat to some degree, and introducing 
a foreign c++ lib binding in its default installation is a very bold move.


Anything into this direction needs proper justification and not just 
handwaving arguments (FUD?), unless there actually is a real 
vulnerability with the current impl.


Cheers,
Jörg

--
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/726fce28-2273-4672-8e00-f8619b95b0d9%40netzkolchose.de.

Re: Should Django use Ada?

[Dylan Reinhold]

I always wonder why people feel the need to belittle others' work with
statements like " But Python, being maintained mostly by volunteers, did
the minimum needed work to fix the vulnerability without really fixing the
urlparse library properly."
But then add something about their time being too valuable to work on
making it better.


Dylan


On Mon, Apr 1, 2024 at 1:37 PM 'Michael Lissner' via Django developers
(Contributions to Django itself)  wrote:

> Hi all,
>
> A few years ago, I reported a vulnerability in Django because Python
> wasn't parsing URLs containing tabs or newlines correctly. In this ticket,
> it was fixed in Python:
>
> https://bugs.python.org/issue43882
>
> But Python, being maintained mostly by volunteers, did the minimum needed
> work to fix the vulnerability without really fixing the urlparse library
> properly.
>
> This means that it's probably still possible to send a URL to django that
> urlparse doesn't know how to handle. When this happens:
>
> 1. It could still be a vulnerability.* If this is the case, Django could
> redirect people to domains where it shouldn't.
>
> 2. It could fail to parse the URL properly, leading to the wrong URL being
> provided to the user.
>
> 3. urlparse could decide it's an invalid URL even though it's not.
>
> This is all pretty bad, but there is some hope in the form of a tool
> called Ada, which aims to actually support URL parsing properly:
>
> Homepage: https://www.ada-url.com/
> Github (more useful, really): https://github.com/ada-url/ada
>
> It's written in C++, is used in Node and Cloudflare Workers. It has
> bindings for Python, Rust, R, and Go. It's licensed under MIT and Apache
> License 2.0. It's fuzzed by Google OSS Fuzzer, and it's much faster than
> urlparse.
>
> I'm curious: Would Django consider switching to this library? I'm not sure
> if I'll have time to do the work, but I can at least open an issue if it's
> a useful switch to make, and I might be able to assign a developer to it if
> this is something we want.
>
> Love to hear thoughts,
>
> Mike
>
>
> * I'm posting this publicly because this kind of vulnerability is really
> well known these days, and exists across most general-purpose languages.
> URLs are just very difficult to parse properly.
>
> --
> 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/f31bc17b-c0c5-4ce4--7d1ec3dfe90bn%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/CAHtg44DJfVrF4ZmUQLVaJyGTCcb%2BcQ4rJZr0%3DV39_f-PwVDTxg%40mail.gmail.com.

Re: Fellow Reports - March 2024

[Mariusz Felisiak]

March 25-26

*Triaged:*
https://code.djangoproject.com/ticket/35330 - The update of related 
objects fails in the admin when the related model is camel case. (accepted)
https://code.djangoproject.com/ticket/35331 - Adding a new related 
entry using the "+" sign from M2M field doesn't update lists. (accepted)
https://code.djangoproject.com/ticket/35332 - Bad performance in 
django.template.load.render_to_string (needsinfo)

*Reviewed/committed:*
https://github.com/django/django/pull/17981 - Fixed #35233 -- Moved 
template engine system checks to backend methods.

*Authored:*
https://github.com/django/djangoproject.com/pull/1494 - Retired myself.
https://github.com/django/django/pull/18015 - Increased test coverage 
for django.db.migrations.operations.special.
https://github.com/django/django/pull/18016 - Removed unused 
_alter_column_collation_sql() in PostgreSQL DatabaseSchemaEditor.
https://github.com/django/django/pull/18022 - Fixed #35329 -- Fixed 
migrations crash when adding partial unique constraints with nulls_distinct.
https://github.com/django/django/pull/18030 - Refs #35234 -- Skipped 
CheckConstraint system checks if not supported.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cba6f73b-38bf-40fc-92bb-a136b760eb3bn%40googlegroups.com.

Re: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

['Michael Lissner' via Django developers (Contributions to Django itself)]

Looks like this issue isn't affecting lots of folks, since nobody is piping 
up, so I'll just add that if anybody arrives here in the future, we'll be 
tracking this in a public issue here: 

https://github.com/freelawproject/courtlistener/issues/3359

My theory is it has something to do with race conditions/timings and async, 
since I *think* it started around the time we started switching to async, 
but others on the team tell me that's a red herring (it's not the cause). 

Anyhow, if anybody ever arrives here in the future, we fixed it 

 
by overriding the save method to catch IntegrityErrors. It's pretty lame to 
have code like this in our save method, but it seems to be working: 

try: 
# Without a transaction wrapper, a failure will invalidate outer 
transactions 
with transaction.atomic(): 
super(Docket, self).save( 
update_fields=update_fields, *args, **kwargs 
) 
except IntegrityError: 
# Temporary patch while we solve #3359 
# If the error is not related to `date_modified` it will raise again 
self.date_modified = timezone.now() 
super(Docket, self).save( 
update_fields=update_fields, *args, **kwargs 
)

Anyhow, thanks for reading, everybody.

On Monday, March 18, 2024 at 7:08:22 AM UTC-7 Matthew Pava wrote:

> Hi Bill,
>
> We ended up using a package called Django-audit-log: 
> https://pypi.org/project/django-audit-log/.
>
> It’s outdated now, but we used the source code for their 
> CreatingUserField, LastUserField, CreationDateTimeField, and 
> ModificationDateTimeField. More modern packages may have enhanced features 
> than these.
>
>  
>
> In your case, I may just add a save method to the abstract model and add 
> timezone.now() to the corresponding fields. If there’s not a pk, then 
> populate the created date field.
>
>  
>
> You are right, though. Perhaps the Django community can explain the issue 
> between auto_now and auto_now_add fields.
>
>  
>
> *From:* 'William Palin' via Django developers (Contributions to Django 
> itself)  
> *Sent:* Sunday, March 17, 2024 9:59 AM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Intermittent IntegrityError on Model Save with auto_now and 
> auto_now_add Fields
>
>  
>
> Hello Django community,
>
>  
>
> We are reaching out after encountering a persistent and elusive issue that 
> manifests as an IntegrityError during the save operation of a Django model. 
> This problem has been sporadically occurring since last year and has 
> successfully stumped four seasoned Django developers on our team. The error 
> seems to involve the non-update of auto_now fields upon model save, leading 
> us to suspect a deeper issue within Django, though we are cautious about 
> drawing premature conclusions. Given the complex and intermittent nature of 
> this bug, we are seeking insights, advice, or any form of guidance from the 
> community.
>
>  
>
> *Issue Overview:*
>
>  
>
> Our model inherits date_created and date_modified fields from an abstract 
> base class designed to standardize these timestamps across our models. Here 
> is how the abstract base class is defined:
>
>  
>
>  
>
> class AbstractDateTimeModel(models.Model):
>
> """An abstract base class for most models"""
>
> 
>
> date_created = models.DateTimeField(
>
> help_text="The moment when the item was created.",
>
> auto_now_add=True,
>
> db_index=True,
>
> )
>
> date_modified = models.DateTimeField(
>
> help_text="The last moment when the item was modified. A value in 
> year"
>
>   " 1750 indicates the value is unknown",
>
> auto_now=True,
>
> db_index=True,
>
> )
>
>  
>
> class Meta:
>
> abstract = True
>
>  
>
> *The Problem:*
>
>  
>
> Intermittently, the .save() method triggers an IntegrityError, apparently 
> because the auto_now field (date_modified) does not get created. A specific 
> instance of this error showed that while date_created is correctly 
> populated, date_modified remains null, which directly leads to the 
> IntegrityError upon attempting to insert the record:
>
>  
>
> [datetime.datetime(2023, 10, 2, 14, 33, 49, 99833, 
> tzinfo=datetime.timezone.utc), None, ...]
>
> 'INSERT INTO "search_docket" ("date_created", "date_modified",... ]
>
>  
>
> *What We've Tried:*
>
>  
>
>- Investigated the possibility of an issue with update_fields being 
>non-null and excluding date_modified during .save(), but confirmed through 
>Sentry logs that update_fields was indeed None in all instances of the 
>error.
>- Attempted to reproduce the issue in a controlled environment without 
>success, leaving us without a clear direction for a solution.
>
>  
>
> *Request for Help:*
>
>  
>
> We're wondering if this could point to an undocumented edge case in 
> 

Re: Fellow Reports - March 2024

[Mariusz Felisiak]

Week ending March 24

*Triaged:*
https://code.djangoproject.com/ticket/35312 - FileNotFoundError escapes 
from run_formatters() (invalid)
https://code.djangoproject.com/ticket/34059 - Validation of check 
constraints on JSONField key transforms with None produces invalid SQL on 
PostgreSQL. (fixed)
https://code.djangoproject.com/ticket/35316 - Support scalars as query 
parameters in admin changelist filters (for backward compatibility). 
(wontfix)
https://code.djangoproject.com/ticket/35318 - QuerySet.exclude() docs 
contain a potentially misleading statement regarding the restrictiveness of 
examples. (invalid)
https://code.djangoproject.com/ticket/35319 - Move the link to add a 
related object inside the .selector-available column for 
FilteredSelectMultiple. (accepted)
https://code.djangoproject.com/ticket/35317 - Add the possibility to do 
prefetches for only a subset of instances (wontfix)
https://code.djangoproject.com/ticket/35321 - Django Admin in Mobile 
Safari zooms in on text inputs (accepted)
https://code.djangoproject.com/ticket/35320 - Remove unnecessary 
django.core.files.move._samefile() hook. (accepted)
https://code.djangoproject.com/ticket/35325 - CharField max_length 
ignored (duplicate)
https://code.djangoproject.com/ticket/35327 - Add note to create custom 
user model in tutorial (wontfix)

*Reviewed/committed:*
https://github.com/django/django/pull/17963 - Refs #31014 -- Added srid 
argument to FromWKB/FromWKT() GIS functions.
https://github.com/django/django/pull/17984 - Fixed #35309 -- Made 
prefetch clear ordering for single-valued relationships.
https://github.com/django/django/pull/17916 - Fixed #35257 -- Corrected 
resolving output_field for IntegerField/DecimalField with NULL.
https://github.com/django/code.djangoproject.com/pull/188 - Fixed #187 
-- Restored support for restructuredtext on wiki pages.
https://github.com/django/django/pull/18000 - Fixed #35320 -- Removed 
unnecessary django.core.files.move._samefile() hook.
https://github.com/django/django/pull/17266 - Fixed #34841 -- Avoided 
rendering apps on state still requiring mutation.
https://github.com/django/django/pull/18001 - Fixed #35323 -- Prevented 
file_move_safe() from trying to overwrite existing file when 
allow_overwrite is False.

*Reviewed:*
https://github.com/django/django/pull/17545 - Updated docs for Django 
releases, including details about fetching and processing translations.

*Authored:*
https://github.com/django/django/pull/17988 - Stopped using 
byte-compiled 3rd-party packages in daily builds for byte-compiled Django.
https://github.com/django/django/pull/17989 - Refs #34059, Refs #34060 
-- Removed outdated warning about validation of JSONField constraints.
https://github.com/django/django/pull/17993 - Fixed ResourceWarning 
from unclosed SQLite connection on Python 3.13+.
https://github.com/django/django/pull/17997 - Fixed ResourceWarning 
from unclosed SQLite connection in test_utils on Python 3.13+.
https://github.com/django/django/pull/18004 - Added 
ModelState.from_model() test for abstract model with unnamed indexes.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/deeba107-d777-48b6-8819-c92d08177cfan%40googlegroups.com.

Re: Fellow Reports - March 2024

[Mariusz Felisiak]

Week ending March 17

*Triaged:*
https://code.djangoproject.com/ticket/35287 - manage createsuperuser 
too restrictive (duplicate)
https://code.djangoproject.com/ticket/35291 - Whitenoise Not Working 
when DEBUG = FALSE - Django - Hosting Static Files (duplicate)
https://code.djangoproject.com/ticket/35290 - Whitenoise Not Working 
when DEBUG = FALSE - Django - Hosting Static Files (invalid)
https://code.djangoproject.com/ticket/35295 - Use INSERT with multiple 
rows on Oracle 23c+ (created)
https://code.djangoproject.com/ticket/35296 - The autoescape parameter 
to Engine() seems to have no effect on Context. (invalid)
https://code.djangoproject.com/ticket/35294 - Queryset explain can be 
truncated. (accepted)
https://code.djangoproject.com/ticket/35299 - Remove ValueError in 
Create method with OneToOne relation (duplicate)
https://code.djangoproject.com/ticket/35300 - Simple COUNT without 
OUTER JOIN (invalid)
https://code.djangoproject.com/ticket/35301 - Overriding a @property of 
an abstract model with a GenericRelation causes a models.E025 error. 
(accepted)
https://code.djangoproject.com/ticket/35303 - Add async implementations 
to contrib.auth backends (accepted)
https://code.djangoproject.com/ticket/35302 - Property on AppConfig and 
ModelAdmin for ordering apps and models in admin sidebar (wontfix)
https://code.djangoproject.com/ticket/35309 - Remove Order by on models 
when prefetching by id (wontfix)
https://code.djangoproject.com/ticket/35307 - make async generic views 
(invalid)
https://code.djangoproject.com/ticket/35305 - No-op rename of field 
with `db_column` drops and recreates constraints/indexes. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/17957 - Fixed #35285 -- Optimized 
ForeignObject._check_unique_target().
https://github.com/django/django/pull/17958 - Fixed #25595 -- Doc'd 
that URLValidator rejects file:// URIs without a host.
https://github.com/django/django/pull/17928 - Fixed #14831 -- Extended 
template style guide in docs.
https://github.com/django/django/pull/17372 - Fixed #34901 -- Added 
async-compatible interface to session engines.
https://github.com/django/django/pull/17971 - Refs #30686 -- Made 
django.utils.html.VOID_ELEMENTS a frozenset.
https://github.com/django/django/pull/17946 - Fixed #35273 -- Fixed 
rendering AdminFileWidget's attributes.
https://github.com/django/django/pull/17950 - Fixed #28541 -- Fixed 
migrations crash when changing primary key on SQLite.
https://github.com/django/django/pull/17973 - Fixed #35294 -- Fixed 
TEXT format of QuerySet.explain() for long plans.
https://github.com/django/django/pull/17985 - Fixed #35301 -- Fixed 
Options._property_names for overriden properties.

*Authored:*
https://github.com/django/django/pull/17964 - Optimized 
DatabaseOperations.bulk_insert_sql() a bit on Oracle.
https://github.com/django/django/pull/17966 - Used 
SessionBase.__setitem__() in setdefault().
https://github.com/django/django/pull/17968 - Removed unused clean() 
method in file-based session.
https://github.com/django/django/pull/17969 - Fixed #35295 -- Used 
INSERT with multiple rows on Oracle 23c.
https://github.com/django/django/pull/17970 - Refs #32673, Refs #35295 
-- Avoided wrapping rhs direct values in lookups.
https://github.com/django/django/pull/17979 - Refs #34900 -- Fixed 
SafeMIMEText.set_payload() crash on Python 3.13.
https://github.com/django/django/pull/17980 - Refs #33996 -- Updated 
CheckConstraint validation on NULL values on Oracle 23c+.
https://github.com/django/django/pull/17982 - Stopped skipping 
model_fields.test_jsonfield.TestQuerying.test_usage_in_subquery on Oracle 
23c.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e65cc0aa-6179-44f6-8217-d572fe46feb9n%40googlegroups.com.

RE: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

['Matthew Pava' via Django developers (Contributions to Django itself)]

Hi Bill,
We ended up using a package called Django-audit-log: 
https://pypi.org/project/django-audit-log/.
It’s outdated now, but we used the source code for their CreatingUserField, 
LastUserField, CreationDateTimeField, and ModificationDateTimeField. More 
modern packages may have enhanced features than these.

In your case, I may just add a save method to the abstract model and add 
timezone.now() to the corresponding fields. If there’s not a pk, then populate 
the created date field.

You are right, though. Perhaps the Django community can explain the issue 
between auto_now and auto_now_add fields.

From: 'William Palin' via Django developers (Contributions to Django itself) 

Sent: Sunday, March 17, 2024 9:59 AM
To: Django developers (Contributions to Django itself) 

Subject: Intermittent IntegrityError on Model Save with auto_now and 
auto_now_add Fields


Hello Django community,



We are reaching out after encountering a persistent and elusive issue that 
manifests as an IntegrityError during the save operation of a Django model. 
This problem has been sporadically occurring since last year and has 
successfully stumped four seasoned Django developers on our team. The error 
seems to involve the non-update of auto_now fields upon model save, leading us 
to suspect a deeper issue within Django, though we are cautious about drawing 
premature conclusions. Given the complex and intermittent nature of this bug, 
we are seeking insights, advice, or any form of guidance from the community.


Issue Overview:



Our model inherits date_created and date_modified fields from an abstract base 
class designed to standardize these timestamps across our models. Here is how 
the abstract base class is defined:




class AbstractDateTimeModel(models.Model):

"""An abstract base class for most models"""



date_created = models.DateTimeField(

help_text="The moment when the item was created.",

auto_now_add=True,

db_index=True,

)

date_modified = models.DateTimeField(

help_text="The last moment when the item was modified. A value in year"

  " 1750 indicates the value is unknown",

auto_now=True,

db_index=True,

)



class Meta:

abstract = True


The Problem:


Intermittently, the .save() method triggers an IntegrityError, apparently 
because the auto_now field (date_modified) does not get created. A specific 
instance of this error showed that while date_created is correctly populated, 
date_modified remains null, which directly leads to the IntegrityError upon 
attempting to insert the record:


[datetime.datetime(2023, 10, 2, 14, 33, 49, 99833, 
tzinfo=datetime.timezone.utc), None, ...]

'INSERT INTO "search_docket" ("date_created", "date_modified",... ]


What We've Tried:



  *   Investigated the possibility of an issue with update_fields being 
non-null and excluding date_modified during .save(), but confirmed through 
Sentry logs that update_fields was indeed None in all instances of the error.
  *   Attempted to reproduce the issue in a controlled environment without 
success, leaving us without a clear direction for a solution.



Request for Help:



We're wondering if this could point to an undocumented edge case in Django's 
auto_now and auto_now_add implementation or a specific database behavior under 
certain conditions. Any advice on further debugging steps, experiences with 
similar issues, or knowledge of potential Django nuances that we might not be 
considering would be incredibly valuable.



We appreciate your time and any feedback or suggestions you can offer.



Thanks



Bill



django v5.0.2

python 3.12.2

db is postgres

--
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/a788c065-3a96-472c-9b41-7c2aebca6967n%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/DS7PR15MB5910838A1CE2563A49DADC61822D2%40DS7PR15MB5910.namprd15.prod.outlook.com.

Re: Use of TIME_INPUT_FORMATS in TimeField

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

USE_I18N does not disable localization, but internationalization. USE_L10N was 
the setting to enable/disable localization, but it was deprecated in Django 
4.0: https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was 
removed completely in Django 5.0, in this commit: 
https://github.com/django/django/commit/8d98f99a4ab5de6f2c730399f53eba8bf6bea470
 .

So I think the phrase “if localization is disabled” is at least a little bit 
wrong. But I don’t think the setting is ignored, as there are tests confirming 
that it works: 
https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/tests/forms_tests/tests/test_input_formats.py#L123-L125
 . The line that reads the setting should be this one: 
https://github.com/django/django/blob/8d98f99a4ab5de6f2c730399f53eba8bf6bea470/django/utils/formats.py#L132
 .

If you can provide a failing minimal project, that would be useful to keep 
debugging. I have some minimal django project templates at 
https://github.com/adamchainz/django-startproject-templates .

On Tue, Mar 5, 2024, at 8:48 AM, Arthur Pemberton wrote:
> Thanks, I'll look into that. But does that mean that 
> settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic 
> flows that lead to it being used.
> 
> On Tue, Mar 5, 2024 at 3:00 AM David Sanders  
> wrote:
>> Define TIME_INPUT_FORMATS in your local formats.py setup as per: 
>> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>> 
>> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>>> The documentation 
>>> (https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says 
>>> that " the default input formats are taken from the active locale format 
>>> `TIME_INPUT_FORMATS` key, or from `TIME_INPUT_FORMATS` 
>>> 
>>>  if localization is disabled". However, neither my reading of the code, or 
>>> my actual experience shows settings.TIME_INPUT_FORMATS ever being used, 
>>> even with "USE_I18N = False"
>>> 
>>> TimeField gets the formats from `input_formats = 
>>> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of 
>>> `formats.get_format` -- the documentation of which says "If use_l10n is 
>>> provided and is not None, it forces the value to be localized (or not), 
>>> otherwise it's always localized."
>>> 
>>> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be 
>>> ignored.
>>> 
>>> How does one use settings.TIME_INPUT_FORMATS ?
>>> 
>>> Arthur Pemberton
>>> 
>>> 
>>> -- 
>>> 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.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/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.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/CA%2BX4dQTQwnqe%3DpJf3bmiZH5LHJ87df%2B8-Rq5LbpLcctp9jNfjA%40mail.gmail.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/490311cc-02cf-4efa-b800-2513e824ff1f%40app.fastmail.com.

Re: Use of TIME_INPUT_FORMATS in TimeField

[Arthur Pemberton]

Thanks, I'll look into that. But does that mean that
settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic
flows that lead to it being used.

On Tue, Mar 5, 2024 at 3:00 AM David Sanders 
wrote:

> Define TIME_INPUT_FORMATS in your local formats.py setup as per:
> https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files
>
> On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:
>
>> The documentation (
>> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
>> that " the default input formats are taken from the active locale format
>> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
>> 
>> if localization is disabled". However, neither my reading of the code, or
>> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
>> even with "USE_I18N = False"
>>
>> TimeField gets the formats from `input_formats =
>> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
>> `formats.get_format` -- the documentation of which says "If use_l10n is
>> provided and is not None, it forces the value to be localized (or not),
>> otherwise it's always localized."
>>
>> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
>> ignored.
>>
>> How does one use settings.TIME_INPUT_FORMATS ?
>>
>> Arthur Pemberton
>>
>> --
>> 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.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/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.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/CA%2BX4dQTQwnqe%3DpJf3bmiZH5LHJ87df%2B8-Rq5LbpLcctp9jNfjA%40mail.gmail.com.

Re: Use of TIME_INPUT_FORMATS in TimeField

[David Sanders]

Define TIME_INPUT_FORMATS in your local formats.py setup as per:
https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files

On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton  wrote:

> The documentation (
> https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says
> that " the default input formats are taken from the active locale format
> TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS
> 
> if localization is disabled". However, neither my reading of the code, or
> my actual experience shows settings.TIME_INPUT_FORMATS ever being used,
> even with "USE_I18N = False"
>
> TimeField gets the formats from `input_formats =
> formats.get_format_lazy("TIME_INPUT_FORMATS")` which is a lazy version of
> `formats.get_format` -- the documentation of which says "If use_l10n is
> provided and is not None, it forces the value to be localized (or not),
> otherwise it's always localized."
>
> so even with "USE_I18N = False" settings.TIME_INPUT_FORMATS seems to be
> ignored.
>
> How does one use settings.TIME_INPUT_FORMATS ?
>
> Arthur Pemberton
>
> --
> 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/CA%2BX4dQRAjfSJnAK9iZ%3DhJMkN%2BTfoShX6%2BNRsjM0oMF6jGDSuZg%40mail.gmail.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/CADyZw-5Vb6K4HQjVbcr1aQGCdozoHkA%2B2Q4Vczp8L63ROX%2BDtQ%40mail.gmail.com.

Re: Fellow Reports - February 2024

[Mariusz Felisiak]

Week ending March 3

*Triaged:*
https://code.djangoproject.com/ticket/35245 - Django freezes on DRF's 
APIView. (invalid)
https://code.djangoproject.com/ticket/35253 - Pagination for 
StackedInline and TabularInline (duplicate)
https://code.djangoproject.com/ticket/35251 - dumpdata refactoring 
(needsinfo)
https://code.djangoproject.com/ticket/35254 - New setting for 
ModelAdmin.list_per_page (wontfix)
https://code.djangoproject.com/ticket/35250 - Stop URL system checks 
from compiling regular expressions (accepted)
https://code.djangoproject.com/ticket/35258 - Rename the 'runserver' 
management command to 'devserver' to be more explicit that it is intended 
for development only (wontfix)
https://code.djangoproject.com/ticket/9990 - Management shell 
autocomplete breaks PYTHONSTARTUP autocomplete (fixed)
https://code.djangoproject.com/ticket/35259 - forms.JSONField validator 
doesn't match documentation behavior (duplicate)
https://code.djangoproject.com/ticket/35260 - request.GET is improperly 
type annotated (invalid)
https://code.djangoproject.com/ticket/35262 - Addindex operation 
generates wrong sql code for Postgresql GinIndex (worksforme)
https://code.djangoproject.com/ticket/35263 - Add keys() and hashes() 
functions to Redis cache backend. (wontfix)
https://code.djangoproject.com/ticket/35264 - CommandError-Conflicting 
migration detected (invalid)
https://code.djangoproject.com/ticket/35265 - Add test for AdminSite 
with custom headers. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/17893 - Fixed #35241 -- Cached 
model's full parent list.
https://github.com/django/django/pull/17901 - Fixed #35246 -- Made 
Field.unique a cached property.
https://github.com/django/django/pull/17907 - Refs #34200 -- Removed 
unnecessary check in DatabaseWrapper.ensure_role() on PostgreSQL.
https://github.com/django/django/pull/17909 - Refs #32114 -- Fixed test 
crash on non-picklable objects in subtests when PickleError is raised.
https://github.com/django/django/pull/17903 - Fixed #29022 -- Fixed 
handling protocol-relative URLs in ManifestStaticFilesStorage when 
STATIC_URL is set to /.
https://github.com/django/djangoproject.com/pull/1486 - Fixed 
doc_test_fixtures.json.
https://github.com/django/django/pull/17483 - Refs #34964 -- Doc'd that 
Q expression order is preserved.
https://github.com/django/django/pull/17880 - Fixed #35198 -- Fixed 
facet filters crash on querysets with no primary key.
https://github.com/django/django/pull/17920 - Refs #35234 -- Moved 
constraint system checks to Check/UniqueConstraint methods.
https://github.com/django/django/pull/17921 - Fixed #35234 -- Added 
system checks for invalid model field names in 
ExclusionConstraint.expressions.
https://github.com/django/django/pull/17876 - Refs #35234 -- Deprecated 
CheckConstraint.check in favor of .condition.
https://github.com/django/django/pull/17925 - Made runserver close 
database connections from migration checks.
https://github.com/django/django/pull/17914 - Refs #33497 -- Added 
connection pool support for PostgreSQL.
https://github.com/django/django/pull/17904 - Fixed #35250 -- Made URL 
system checks use uncompiled regexes.

*Authored:*
https://github.com/django/django/pull/17915 - Removed #django-geo IRC 
channel in docs.
https://github.com/django/django/pull/17918 - Refs #35090 -- Fixed 
urlpatterns.tests.SimplifiedURLTests when run in reverse.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7ad806ce-b38b-405d-86bf-80780cfcf960n%40googlegroups.com.

Re: Fellow Reports - February 2024

[Mariusz Felisiak]

Week ending February 25

*Triaged:*
https://code.djangoproject.com/ticket/35232 - Cache 
Options.verbose_name_raw (accepted)
https://code.djangoproject.com/ticket/35234 - 
ExclusionConstraint.expressions should be checked for foreign relationship 
references (accepted)
https://code.djangoproject.com/ticket/35225 - Tests of ordering by JSON 
field fail in Oracle 21c (needsinfo)
https://code.djangoproject.com/ticket/35226 - Dynamically created 
connection are disallowed in SimpleTestCase and subclasses. (accepted)
https://code.djangoproject.com/ticket/29167 - HashedFilesMixin doesn't 
work with data URIs that include a closing parenthesis (worksforme)
https://code.djangoproject.com/ticket/35231 - Add system checks for 
settings types (wontfix)
https://code.djangoproject.com/ticket/35236 - Access Field.attname and 
Field.column directly (accepted)
https://code.djangoproject.com/ticket/35235 - ArrayAgg() doesn't return 
default when filter contains __in=[]. (accepted)
https://code.djangoproject.com/ticket/35237 - Optimize system checks 
for admin actions (accepted)
https://code.djangoproject.com/ticket/35244 - URL resolution does not 
work with a namespaced function reference. (duplicate)
https://code.djangoproject.com/ticket/35249 - 
DISABLE_SERVER_SIDE_CURSORS is not documented as a connection setting 
 (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/17873 - Fixed #35230 -- Added 
cached ForeignObjectRel.accessor_name.
https://github.com/django/django/pull/17872 - Fixed #35229 -- Made URL 
custom error handler check run once.
https://github.com/django/django/pull/17874 - Fixed #35232 -- Cached 
model's Options.verbose_name_raw.
https://github.com/django/django/pull/17867 - Refs #34060 -- Fixed 
JSONField __exact lookup for primitivies on Oracle 21c+.
https://github.com/django/django/pull/17863 - Fixed #35224 -- Made 
GenericForeignKey inherit from Field.
https://github.com/django/django/pull/17862 - Refs #28011 -- Removed 
ForeignObjectRel.is_hidden().
https://github.com/django/django/pull/17884 - Fixed #35153 -- Added 
note about locale name notation to FORMAT_MODULE_PATH docs.
https://github.com/django/django/pull/17868 - Used  instead of 
 in admin theme button.
https://github.com/django/django/pull/17887 - Fixed #35236 -- Used 
Field.attname/column attributes instead of 
get_attname()/get_attname_column().
https://github.com/django/django/pull/17881 - Fixed #23759 -- Preserved 
all file extensions in Storage.get_available_name().
https://github.com/django/django/pull/17889 - Fixed #35238 -- Fixed 
database serialization crash when base managers use prefetch_related().
https://github.com/django/django/pull/17888 - Fixed #35237 -- Merged 
system checks for admin actions.
https://github.com/django/django/pull/17892 - Removed distracting note 
from tutorial 4.
https://github.com/django/code.djangoproject.com/pull/181 - Added tests 
for list of installed components.
https://github.com/django/django/pull/17650 - Fixed #32114 -- Fixed 
parallel test crash on non-picklable objects in subtests.
https://github.com/django/django/pull/17870 - Refs #30950, Refs #35187 
-- Added tests for byte-compiled Django to daily builds.
https://github.com/django/code.djangoproject.com/pull/182 - Updated 
TracSpamFilter.
https://github.com/django/code.djangoproject.com/pull/183 - Updated to 
Django 3.2.
https://github.com/django/djangoproject.com/pull/1485 - Upgraded 
django-recaptcha to 4.0.0.
https://github.com/django/django/pull/17894 - Fixed #35140 -- Increased 
font size in debug views.
https://github.com/django/django/pull/17703 - Fixed #35090 -- 
Deprecated registering URL converters with the same name.

*Authored:*
https://github.com/django/django/pull/17878 - Fixed closing connections 
in test_utils.tests.AllowedDatabaseQueriesTests.
https://github.com/django/django/pull/17879 - Fixed #35226 -- Reallowed 
executing queries for dynamically created connections.
https://github.com/django/django/pull/17891 - Refs #34900 -- Fixed 
CommandTypes.test_help_default_options_with_custom_arguments test on Python 
3.13+.
https://github.com/django/django/pull/17895 - Removed obsolete 
test_get_or_create_raises_IntegrityError_plus_traceback() test.
https://github.com/django/django/pull/17898 - Refs #32114 -- Fixed 
RemoteTestResultTest.test_unpicklable_subtest test without tblib.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/116bb382-93d5-4d2f-9e8a-e1812bd78874n%40googlegroups.com.

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

[Ryoma Han]

I've found the reason why I've been thinking this wrong way. 

`getattr(self.get_queryset(), name)` is getting a bound method from 
Manager.get_queryset() which is a QuerySet class instance, while method is 
getting function from _queryset_class.

The difference is one of them is bound method, while the other is function.

在2024年2月28日星期三 UTC+8 10:13:09 写道：

> Hi Ryoma, a good way to investigate this would be to make the change and 
> see if anything breaks. 
>
> If I understand correctly, your suggest is:
>
> -return getattr(self.get_queryset(), name)(*args, **kwargs)
> +return method(*args, **kwargs)
>
> In that case, running the test suite gives this error:
>
>   File "/home/tim/code/django/django/db/models/manager.py", line 89, in 
> manager_method
> return method(*args, **kwargs)
>^^^
> TypeError: QuerySet.using() missing 1 required positional argument: 'alias'
>
> I leave further investigation to you. :-)
> On Tuesday, February 27, 2024 at 7:28:05 PM UTC-5 Ryoma Han wrote:
>
>> I've been reading through the Django source code the last few days. When 
>> I was reading the BaseManager source code I saw a method like this:
>>
>> ```python
>> @classmethod
>> def _get_queryset_methods(cls, queryset_class):
>> def create_method(name, method):
>> @wraps(method)
>> def manager_method(self, *args, **kwargs):
>> return getattr(self.get_queryset(), name)(*args, **kwargs)
>>
>> return manager_method
>>
>> new_methods = {}
>> for name, method in inspect.getmembers(
>> queryset_class, predicate=inspect.isfunction
>> ):
>> if hasattr(cls, name):
>> continue
>> queryset_only = getattr(method, "queryset_only", None)
>> if queryset_only or (queryset_only is None and 
>> name.startswith("_")):
>> continue
>> new_methods[name] = create_method(name, method)
>> return new_methods
>> ```
>>
>> My question is why we use `getattr(self.get_queryset(), name)` insted of 
>> just use `method`.
>>
>

-- 
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/b6b6ea24-3baa-461c-b5b2-27f1128eb92bn%40googlegroups.com.

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

[Ryoma Han]

Thanks for your answer. I will continue to investigate based on your 
suggestions and if I find the answer I will respond again.

在2024年2月28日星期三 UTC+8 10:13:09 写道：

> Hi Ryoma, a good way to investigate this would be to make the change and 
> see if anything breaks. 
>
> If I understand correctly, your suggest is:
>
> -return getattr(self.get_queryset(), name)(*args, **kwargs)
> +return method(*args, **kwargs)
>
> In that case, running the test suite gives this error:
>
>   File "/home/tim/code/django/django/db/models/manager.py", line 89, in 
> manager_method
> return method(*args, **kwargs)
>^^^
> TypeError: QuerySet.using() missing 1 required positional argument: 'alias'
>
> I leave further investigation to you. :-)
> On Tuesday, February 27, 2024 at 7:28:05 PM UTC-5 Ryoma Han wrote:
>
>> I've been reading through the Django source code the last few days. When 
>> I was reading the BaseManager source code I saw a method like this:
>>
>> ```python
>> @classmethod
>> def _get_queryset_methods(cls, queryset_class):
>> def create_method(name, method):
>> @wraps(method)
>> def manager_method(self, *args, **kwargs):
>> return getattr(self.get_queryset(), name)(*args, **kwargs)
>>
>> return manager_method
>>
>> new_methods = {}
>> for name, method in inspect.getmembers(
>> queryset_class, predicate=inspect.isfunction
>> ):
>> if hasattr(cls, name):
>> continue
>> queryset_only = getattr(method, "queryset_only", None)
>> if queryset_only or (queryset_only is None and 
>> name.startswith("_")):
>> continue
>> new_methods[name] = create_method(name, method)
>> return new_methods
>> ```
>>
>> My question is why we use `getattr(self.get_queryset(), name)` insted of 
>> just use `method`.
>>
>

-- 
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/4292768f-527a-4155-a48e-1d766439c4c8n%40googlegroups.com.

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

[Tim Graham]

Hi Ryoma, a good way to investigate this would be to make the change and 
see if anything breaks. 

If I understand correctly, your suggest is:

-return getattr(self.get_queryset(), name)(*args, **kwargs)
+return method(*args, **kwargs)

In that case, running the test suite gives this error:

  File "/home/tim/code/django/django/db/models/manager.py", line 89, in 
manager_method
return method(*args, **kwargs)
   ^^^
TypeError: QuerySet.using() missing 1 required positional argument: 'alias'

I leave further investigation to you. :-)
On Tuesday, February 27, 2024 at 7:28:05 PM UTC-5 Ryoma Han wrote:

> I've been reading through the Django source code the last few days. When I 
> was reading the BaseManager source code I saw a method like this:
>
> ```python
> @classmethod
> def _get_queryset_methods(cls, queryset_class):
> def create_method(name, method):
> @wraps(method)
> def manager_method(self, *args, **kwargs):
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>
> return manager_method
>
> new_methods = {}
> for name, method in inspect.getmembers(
> queryset_class, predicate=inspect.isfunction
> ):
> if hasattr(cls, name):
> continue
> queryset_only = getattr(method, "queryset_only", None)
> if queryset_only or (queryset_only is None and 
> name.startswith("_")):
> continue
> new_methods[name] = create_method(name, method)
> return new_methods
> ```
>
> My question is why we use `getattr(self.get_queryset(), name)` insted of 
> just use `method`.
>

-- 
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/86389eb3-c16f-42d6-ae0d-983038734598n%40googlegroups.com.

Re: Deprecate CICharField, CIEmailField, CITextField

[Silvio]

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 supported, so I think some code has to remain)

On Thursday, February 22, 2024 at 3:13:40 AM UTC-5 Johannes Maron wrote:

> 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 sponsor to ensure 
> maintenance.
>
> It takes one pip install and a sed command to replace some imports, and 
> you grab a coffee and forget about it.
>
> Am Do., 22. Feb. 2024 um 01:59 Uhr schrieb Silvio :
>
>> 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:

Re: Deprecate CICharField, CIEmailField, CITextField

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

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 sponsor to ensure maintenance.

It takes one pip install and a sed command to replace some imports, and you
grab a coffee and forget about it.

Am Do., 22. Feb. 2024 um 01:59 Uhr schrieb Silvio :

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

Re: Deprecate CICharField, CIEmailField, CITextField

[Silvio]

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

Re: Fellow Reports - February 2024

[Mariusz Felisiak]

Week ending February 18

*Triaged:*
https://code.djangoproject.com/ticket/35181 - behaviour of makemessage 
dont follow documentation (needsinfo)
https://code.djangoproject.com/ticket/35185 - Daphne: websocket works 
locally with ws protocol, but it connects and quickly disconnects in 
production (invalid)
https://code.djangoproject.com/ticket/35183 - Run only a random subset 
of tests. (wontfix)
https://code.djangoproject.com/ticket/35186 - Script run as manage.py 
command gets frequent django.db.utils.InterfaceError: connection already 
closed errors (duplicate)
https://code.djangoproject.com/ticket/35180 - PostgreSQL pattern ops 
indexes are dropped when changing between CharField and TextField 
(duplicate)
https://code.djangoproject.com/ticket/35194 - Postgres 16.2 with 
_iexact leads to IndeterminateCollation (needsinfo)
https://code.djangoproject.com/ticket/35191 - Allow form renderer to 
use custom template for label tag (wontfix)
https://code.djangoproject.com/ticket/35193 - Range dumper assumes 
timezone aware datetimes. (invalid)
https://code.djangoproject.com/ticket/35195 - Remove type="text/css" 
from 

Re: Proposal for SyncChatRoom Integration in Django

[Fawemimo Owolabi]

That sounds great, I will keep you updated for any technologies to use or
have you have any technical issues also keep me updated

On Sun, Feb 18, 2024, 03:08 David Ansa  wrote:

> Hi Fawemimo Owolabi,
>
> Thank you for your support and feedback! I appreciate your suggestion to
> use SyncChatRoom as a third-party package, and I'm considering extending it
> to integrate with Django REST Framework as well.
>
> I'll keep the community updated on the progress, and feel free to share
> any further thoughts or ideas you may have.
>
> Best regards,
> David Ansa
>
> On Friday, February 16, 2024 at 5:52:53 PM UTC+1 Fawemimo Owolabi wrote:
>
>> I really support these motions, it really sound great but it will be best
>> to used as a third-party package, also for drf as well
>>
>> On Tuesday, February 13, 2024 at 11:21:02 PM UTC+1 Adam Johnson wrote:
>>
>>> Hi David
>>>
>>> SyncChatRoom sounds more like something that Django would help users
>>> build, rather than include in the framework. If it’s somewhat reusable
>>> between projects, it would be best be published as a third-party package.
>>>
>>> Thanks,
>>>
>>> Adam
>>>
>>> On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote:
>>>
>>> Hi Everyone,
>>>
>>> I'm excited to propose the integration of SyncChatRoom, a real-time chat
>>> functionality, into the Django framework. SyncChatRoom aims to provide
>>> native support for WebSocket communication, making it easier for developers
>>> to implement real-time chat features in their Django applications.
>>>
>>>
>>> *Proposal Summary:*
>>>
>>>- Feature Name: SyncChatRoom
>>>- Purpose: Enable Django developers to seamlessly integrate
>>>real-time chat functionality, enhancing user engagement and 
>>> collaboration.
>>>- Implementation: Utilize Django Channels for WebSocket support and
>>>provide a set of APIs and components for real-time communication.
>>>
>>> *Use Cases:*
>>>
>>>- Live chat applications
>>>- Collaborative editing platforms
>>>- Real-time notifications
>>>
>>> *Why SyncChatRoom?*
>>>
>>> Real-time communication is crucial for modern web applications.
>>> SyncChatRoom aligns with Django's commitment to staying relevant and
>>> user-friendly.
>>>
>>> *Technical Details:*
>>>
>>>- SyncChatRoom will leverage Django Channels for WebSocket support.
>>>- Detailed technical specifications and design considerations will
>>>be discussed during the development process.
>>>
>>>
>>> *Potential Benefits:*
>>>
>>>- Easier integration of real-time features in Django projects.
>>>- Consistent and standardized implementation across the Django
>>>ecosystem.
>>>
>>>
>>> I'm thrilled about the potential of SyncChatRoom and look forward to
>>> hearing your thoughts and suggestions. Let's discuss how we can make Django
>>> even more powerful in the realm of real-time communication!
>>>
>>>
>>> --
>>> 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/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%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/1506f3ca-325b-4355-bd98-ed5374e43ff5n%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/CANfEbGJ%2BaKLEfPw2DMGj6Lra1Fm9zs0s3bAq2wMxifzymAyqAA%40mail.gmail.com.

Re: Proposal for SyncChatRoom Integration in Django

[David Ansa]

Hi Fawemimo Owolabi,

Thank you for your support and feedback! I appreciate your suggestion to 
use SyncChatRoom as a third-party package, and I'm considering extending it 
to integrate with Django REST Framework as well.

I'll keep the community updated on the progress, and feel free to share any 
further thoughts or ideas you may have.

Best regards,
David Ansa

On Friday, February 16, 2024 at 5:52:53 PM UTC+1 Fawemimo Owolabi wrote:

> I really support these motions, it really sound great but it will be best 
> to used as a third-party package, also for drf as well
>
> On Tuesday, February 13, 2024 at 11:21:02 PM UTC+1 Adam Johnson wrote:
>
>> Hi David
>>
>> SyncChatRoom sounds more like something that Django would help users 
>> build, rather than include in the framework. If it’s somewhat reusable 
>> between projects, it would be best be published as a third-party package.
>>
>> Thanks,
>>
>> Adam
>>
>> On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote:
>>
>> Hi Everyone,
>>
>> I'm excited to propose the integration of SyncChatRoom, a real-time chat 
>> functionality, into the Django framework. SyncChatRoom aims to provide 
>> native support for WebSocket communication, making it easier for developers 
>> to implement real-time chat features in their Django applications.
>>
>>
>> *Proposal Summary:*
>>
>>- Feature Name: SyncChatRoom
>>- Purpose: Enable Django developers to seamlessly integrate real-time 
>>chat functionality, enhancing user engagement and collaboration.
>>- Implementation: Utilize Django Channels for WebSocket support and 
>>provide a set of APIs and components for real-time communication.
>>
>> *Use Cases:*
>>
>>- Live chat applications
>>- Collaborative editing platforms
>>- Real-time notifications
>>
>> *Why SyncChatRoom?*
>>
>> Real-time communication is crucial for modern web applications.
>> SyncChatRoom aligns with Django's commitment to staying relevant and 
>> user-friendly.
>>
>> *Technical Details:*
>>
>>- SyncChatRoom will leverage Django Channels for WebSocket support.
>>- Detailed technical specifications and design considerations will be 
>>discussed during the development process.
>>
>>
>> *Potential Benefits:*
>>
>>- Easier integration of real-time features in Django projects.
>>- Consistent and standardized implementation across the Django 
>>ecosystem.
>>
>>
>> I'm thrilled about the potential of SyncChatRoom and look forward to 
>> hearing your thoughts and suggestions. Let's discuss how we can make Django 
>> even more powerful in the realm of real-time communication!
>>
>>
>> -- 
>> 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/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%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/1506f3ca-325b-4355-bd98-ed5374e43ff5n%40googlegroups.com.

Re: New feature request - Run only a random subset of tests.

[Jason Johns]

agreed about this is a unittest/pytest specific focus, not django.

This is pretty straightforward to do with pytest, can have a custom flag 
and then randomize the test collection.  With unittest, not sure.

On Monday, February 12, 2024 at 11:36:57 AM UTC-5 Jörg Breitbart wrote:

> I also think that your requirements are too specific to be added to 
> django. You are prolly better suited by creating your own test picking 
> abstraction for this, e.g. by writing custom test suite aggregates or 
> using unittest.TestLoader.discover and going into tests of interest by 
> your own logic (assuming you are sticking to unittest for testing).
>

-- 
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/e0732ebc-9aa4-49c8-9193-ff32517bb421n%40googlegroups.com.

Re: Proposal for SyncChatRoom Integration in Django

[Fawemimo Owolabi]

I really support these motions, it really sound great but it will be best 
to used as a third-party package, also for drf as well

On Tuesday, February 13, 2024 at 11:21:02 PM UTC+1 Adam Johnson wrote:

> Hi David
>
> SyncChatRoom sounds more like something that Django would help users 
> build, rather than include in the framework. If it’s somewhat reusable 
> between projects, it would be best be published as a third-party package.
>
> Thanks,
>
> Adam
>
> On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote:
>
> Hi Everyone,
>
> I'm excited to propose the integration of SyncChatRoom, a real-time chat 
> functionality, into the Django framework. SyncChatRoom aims to provide 
> native support for WebSocket communication, making it easier for developers 
> to implement real-time chat features in their Django applications.
>
>
> *Proposal Summary:*
>
>- Feature Name: SyncChatRoom
>- Purpose: Enable Django developers to seamlessly integrate real-time 
>chat functionality, enhancing user engagement and collaboration.
>- Implementation: Utilize Django Channels for WebSocket support and 
>provide a set of APIs and components for real-time communication.
>
> *Use Cases:*
>
>- Live chat applications
>- Collaborative editing platforms
>- Real-time notifications
>
> *Why SyncChatRoom?*
>
> Real-time communication is crucial for modern web applications.
> SyncChatRoom aligns with Django's commitment to staying relevant and 
> user-friendly.
>
> *Technical Details:*
>
>- SyncChatRoom will leverage Django Channels for WebSocket support.
>- Detailed technical specifications and design considerations will be 
>discussed during the development process.
>
>
> *Potential Benefits:*
>
>- Easier integration of real-time features in Django projects.
>- Consistent and standardized implementation across the Django 
>ecosystem.
>
>
> I'm thrilled about the potential of SyncChatRoom and look forward to 
> hearing your thoughts and suggestions. Let's discuss how we can make Django 
> even more powerful in the realm of real-time communication!
>
>
> -- 
> 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/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%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/0fbad1ca-62fc-4273-8ea4-5e0a8151d4b9n%40googlegroups.com.

Re: Proposal for SyncChatRoom Integration in Django

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

Hi David

SyncChatRoom sounds more like something that Django would help users build, 
rather than include in the framework. If it’s somewhat reusable between 
projects, it would be best be published as a third-party package.

Thanks,

Adam

On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote:
> Hi Everyone,
> 
> I'm excited to propose the integration of SyncChatRoom, a real-time chat 
> functionality, into the Django framework. SyncChatRoom aims to provide native 
> support for WebSocket communication, making it easier for developers to 
> implement real-time chat features in their Django applications.
> 
> *Proposal Summary:
*
>  • Feature Name: SyncChatRoom
>  • Purpose: Enable Django developers to seamlessly integrate real-time chat 
> functionality, enhancing user engagement and collaboration.
>  • Implementation: Utilize Django Channels for WebSocket support and provide 
> a set of APIs and components for real-time communication.
> *Use Cases:*
>  • Live chat applications
>  • Collaborative editing platforms
>  • Real-time notifications
> *Why SyncChatRoom?*
> 
> Real-time communication is crucial for modern web applications.
> SyncChatRoom aligns with Django's commitment to staying relevant and 
> user-friendly.
> 
> *Technical Details:*
>  • SyncChatRoom will leverage Django Channels for WebSocket support.
>  • Detailed technical specifications and design considerations will be 
> discussed during the development process.
> 
> *Potential Benefits:*
>  • Easier integration of real-time features in Django projects.
>  • Consistent and standardized implementation across the Django ecosystem.
> 
> I'm thrilled about the potential of SyncChatRoom and look forward to hearing 
> your thoughts and suggestions. Let's discuss how we can make Django even more 
> powerful in the realm of real-time communication!
> 
> 
> -- 
> 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/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%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/ad3ce392-0ccf-4343-b2f2-1135c1ae91a9%40app.fastmail.com.

Re: Testing Unmanaged Models - Using the SchemaEditor to create db tables

[Emmanuel Katchy]

Hi Adam,

Thanks for your response!

I understand your point about unmanaged models being a niche use case of 
Django. I've decided to proceed with creating a package and see how it goes.

The new enterContext() and other methods in unittest seem interesting. I'll 
definitely be using them more from now on.

Best,
Emmanuel

On Friday, February 9, 2024 at 11:23:36 PM UTC+1 Adam Johnson wrote:

> Hi Emmanuel
>
> Most activity from this mailing list has moved to Django Internals 
> category on the forum: https://forum.djangoproject.com/c/internals/5 . 
> Better to post there in future, or you could even duplicate this post.
>
> I think your approach is worth sharing in a blog post, or even a package, 
> rather than adding to Django itself.  Your code is worth sharing but may be 
> too specific for the framework.
>
> Unmanaged models aren’t particularly popular. When they are used, it can 
> be for many reasons. As a result, projects may create the tables in various 
> ways during tests, such as loading an existing database dump or calling an 
> external tool. So using Django’s migrations to create them (through 
> managed=True or SchemaEditor) is just one option among many.
>
> By the way, you may be able to simplify your implementation with the new 
> context methods in unittest from Python 3.11: 
> https://adamj.eu/tech/2022/11/14/unittest-context-methods-python-3-11-backports/
>  
> .
>
> Thank you for sharing, and welcome to the Django community!
>
> On Sun, Jan 28, 2024, at 11:00 PM, Emmanuel Katchy wrote:
>
> Hi everyone!
>
> I'd like to get your thoughts on something.
>
> Unmanaged models mean that Django no longer handles creating and managing 
> schema at the database level (hence the name).
> When running tests, this means these tables aren't created, and we can't 
> run queries against that model. The general solution I found is to 
> monkey-patch 
> the TestSuiteRunner to temporarily treat models as managed 
> 
> .
>
> Doing a bit of research I however came up with a solution using 
> SchemaEditor , 
> to create the model tables directly, viz:
>
> ```
> """
> A cleaner approach to temporarily creating unmanaged model db tables for 
> tests
> """
>
> from unittest import TestCase
>
> from django.db import connections, models
>
> class create_unmanaged_model_tables:
> """
> Create db tables for unmanaged models for tests
> Adapted from: https://stackoverflow.com/a/49800437
> Examples:
> with create_unmanaged_model_tables(UnmanagedModel):
> ...
> @create_unmanaged_model_tables(UnmanagedModel, FooModel)
> def test_generate_data():
> ...
> 
> @create_unmanaged_model_tables(UnmanagedModel, FooModel)
> def MyTestCase(unittest.TestCase):
> ...
> """
>
> def __init__(self, unmanaged_models: list[ModelBase], db_alias: str = 
> "default"):
> """
> :param str db_alias: Name of the database to connect to, defaults 
> to "default"
> """
> self.unmanaged_models = unmanaged_models
> self.db_alias = db_alias
> self.connection = connections[db_alias]
>
> def __call__(self, obj):
> if issubclass(obj, TestCase):
> return self.decorate_class(obj)
> return self.decorate_callable(obj)
>
> def __enter__(self):
> self.start()
>
> def __exit__(self, exc_type, exc_value, traceback):
> self.stop()
>
> def start(self):
> with self.connection.schema_editor() as schema_editor:
> for model in self.unmanaged_models:
> schema_editor.create_model(model)
>
> if (
> model._meta.db_table
> not in self.connection.introspection.table_names()
> ):
> raise ValueError(
> "Table `{table_name}` is missing in test 
> database.".format(
> table_name=model._meta.db_table
> )
> )
>
> def stop(self):
> with self.connection.schema_editor() as schema_editor:
> for model in self.unmanaged_models:
> schema_editor.delete_model(model)
>
> def copy(self):
> return self.__class__(
> unmanaged_models=self.unmanaged_models, db_alias=self.db_alias
> )
>
> def decorate_class(self, klass):
> # Modify setUpClass and tearDownClass
> orig_setUpClass = klass.setUpClass
> orig_tearDownClass = klass.tearDownClass
>
> @classmethod
> def setUpClass(cls):
> self.start()
> if orig_setUpClass is not None:
> orig_setUpClass()
>
>
> @classmethod
> def tearDownClass(cls):
> if orig_tearDownClass 

Re: New feature request - Run only a random subset of tests.

[Jörg Breitbart]

I also think that your requirements are too specific to be added to 
django. You are prolly better suited by creating your own test picking 
abstraction for this, e.g. by writing custom test suite aggregates or 
using unittest.TestLoader.discover and going into tests of interest by 
your own logic (assuming you are sticking to unittest for testing).


--
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/cef0a8f2-7ea7-45ea-ade9-e3522b1e2518%40netzkolchose.de.

Re: New feature request - Run only a random subset of tests.

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

I’d be against this. I think this approach would be counterproductive in most 
cases due to the high probability of a false positive. Including it as a core 
feature is not necessary when it can be added through a third party package.

On Mon, Feb 12, 2024, at 2:22 PM, אורי wrote:
> Hi,
> 
> Also, sometimes I just want to see how many tests are in a specific module, 
> without running them. So I can just run 
> `./tests_manage_all_sites_with_all_warnings.sh test speedy.net --test-only 0 
> --test-all-languages` which gives me the number of tests in speedy.net, or 
> any module I need. There is no way to count them from code, because many of 
> them are tested more than once so the only way to know how many tests are in 
> a specific module is to run them.
> 
> Thanks,
> Uri.
> 
> 
> אורי
> u...@speedy.net
> 
> 
> On Mon, Feb 12, 2024 at 3:36 PM Jörg Breitbart  
> wrote:
>> @Uri
>> 
>> May I ask, whats the idea behind running a random subset of tests only? 
>> Wouldn't a Monte Carlo approach be highly unreliable, e.g. lure ppl into 
>> thinking everything is ok, but in reality the random test selection did 
>> not catch affected code paths? I mean for tests - its all about 
>> reliability, isn't it? And 200 out of 6k tests sounds like running often 
>> into false positive test results, esp. if your test base is skewed 
>> towards features not being affected by current changes.
>> 
>> I think this could still work with a better reliability / changed code 
>> coverage, if the abstraction is a bit more complicated, e.g.:
>> - introduce grouping flags on tests - on module, class or even single 
>> method scope
>> - on test run, declare what flags should be tested (runs all test with 
>> given flags)
>> - alternatively use appropriate flags reflecting your code changes + 
>> your test counter on top, but now it selects from the flagged tests with 
>> higher probability to run affected tests
>> 
>> Ah well, just some quick thoughts on that...
>> 
>> Cheers,
>> Jörg
>> 
>> -- 
>> 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/0138232b-4b8f-4a7a-99b0-67c0702f9ce8%40netzkolchose.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/CABD5YeEQ3hBNEZBhR68iiHCRkFRqr9B9jNg%3DtgsN4OwC3%3D9rLg%40mail.gmail.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/e3fe4559-e37c-47ce-86b5-8c9d6385f048%40app.fastmail.com.

Re: New feature request - Run only a random subset of tests.

[אורי]

Hi,

Also, sometimes I just want to see how many tests are in a specific module,
without running them. So I can just run
`./tests_manage_all_sites_with_all_warnings.sh test speedy.net --test-only
0 --test-all-languages` which gives me the number of tests in speedy.net,
or any module I need. There is no way to count them from code, because many
of them are tested more than once so the only way to know how many tests
are in a specific module is to run them.

Thanks,
Uri.


אורי
u...@speedy.net


On Mon, Feb 12, 2024 at 3:36 PM Jörg Breitbart 
wrote:

> @Uri
>
> May I ask, whats the idea behind running a random subset of tests only?
> Wouldn't a Monte Carlo approach be highly unreliable, e.g. lure ppl into
> thinking everything is ok, but in reality the random test selection did
> not catch affected code paths? I mean for tests - its all about
> reliability, isn't it? And 200 out of 6k tests sounds like running often
> into false positive test results, esp. if your test base is skewed
> towards features not being affected by current changes.
>
> I think this could still work with a better reliability / changed code
> coverage, if the abstraction is a bit more complicated, e.g.:
> - introduce grouping flags on tests - on module, class or even single
> method scope
> - on test run, declare what flags should be tested (runs all test with
> given flags)
> - alternatively use appropriate flags reflecting your code changes +
> your test counter on top, but now it selects from the flagged tests with
> higher probability to run affected tests
>
> Ah well, just some quick thoughts on that...
>
> Cheers,
> Jörg
>
> --
> 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/0138232b-4b8f-4a7a-99b0-67c0702f9ce8%40netzkolchose.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/CABD5YeEQ3hBNEZBhR68iiHCRkFRqr9B9jNg%3DtgsN4OwC3%3D9rLg%40mail.gmail.com.

Re: New feature request - Run only a random subset of tests.

[אורי]

Hi Jörg,

All our tests are tested anyway with GitHub Actions. The idea is to run a
subset of tests locally to catch 90% of the problems before I commit and
wait 40 minutes for all the tests to run. It works most of the time. Of
course the whole tests should be run before deploying to production, but
running a subset of tests improves productivity in locating errors without
having to wait for the full test suit to run.

(by the way, running all our tests take 90 minutes, but we skip many tests
and run them in random anyway - we have 11 languages and we always test 3
specific languages + another language selected by random. This is how we
reduce the time from 90 minutes to 40 minutes. And if we make changes in
languages, we can wait 90 minutes and run all the tests)

I also can run specific tests if I work on a specific module. For example
if I work on a specific view - I can run only tests of this view. But
again, of course we run all the tests before we deploy to production.

Thanks,
Uri.
אורי
u...@speedy.net


On Mon, Feb 12, 2024 at 3:36 PM Jörg Breitbart 
wrote:

> @Uri
>
> May I ask, whats the idea behind running a random subset of tests only?
> Wouldn't a Monte Carlo approach be highly unreliable, e.g. lure ppl into
> thinking everything is ok, but in reality the random test selection did
> not catch affected code paths? I mean for tests - its all about
> reliability, isn't it? And 200 out of 6k tests sounds like running often
> into false positive test results, esp. if your test base is skewed
> towards features not being affected by current changes.
>
> I think this could still work with a better reliability / changed code
> coverage, if the abstraction is a bit more complicated, e.g.:
> - introduce grouping flags on tests - on module, class or even single
> method scope
> - on test run, declare what flags should be tested (runs all test with
> given flags)
> - alternatively use appropriate flags reflecting your code changes +
> your test counter on top, but now it selects from the flagged tests with
> higher probability to run affected tests
>
> Ah well, just some quick thoughts on that...
>
> Cheers,
> Jörg
>
> --
> 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/0138232b-4b8f-4a7a-99b0-67c0702f9ce8%40netzkolchose.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/CABD5YeFeq_Y66GgjUD-OXP0%3D_v5LZLzC2bg4h6qaASzri0zSyA%40mail.gmail.com.

Re: New feature request - Run only a random subset of tests.

[Jörg Breitbart]

Adding to my last comment:

If you are looking for a more tailored unit testing with low test 
pressure and still high reliability - maybe coverage.py can give you 
enough code insights to build a tailored test index db to only run 
affected tests from current code changes. I am not aware of test 
frameworks doing that currently, but it should give you high confidence 
in the test results w'o running them all over and over.


--
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/5e7558d3-c9a4-483b-94e6-1b781e77c7c0%40netzkolchose.de.

Re: New feature request - Run only a random subset of tests.

[Jörg Breitbart]

@Uri

May I ask, whats the idea behind running a random subset of tests only? 
Wouldn't a Monte Carlo approach be highly unreliable, e.g. lure ppl into 
thinking everything is ok, but in reality the random test selection did 
not catch affected code paths? I mean for tests - its all about 
reliability, isn't it? And 200 out of 6k tests sounds like running often 
into false positive test results, esp. if your test base is skewed 
towards features not being affected by current changes.


I think this could still work with a better reliability / changed code 
coverage, if the abstraction is a bit more complicated, e.g.:
- introduce grouping flags on tests - on module, class or even single 
method scope
- on test run, declare what flags should be tested (runs all test with 
given flags)
- alternatively use appropriate flags reflecting your code changes + 
your test counter on top, but now it selects from the flagged tests with 
higher probability to run affected tests


Ah well, just some quick thoughts on that...

Cheers,
Jörg

--
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/0138232b-4b8f-4a7a-99b0-67c0702f9ce8%40netzkolchose.de.

Re: Testing Unmanaged Models - Using the SchemaEditor to create db tables

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

Hi Emmanuel

Most activity from this mailing list has moved to Django Internals category on 
the forum: https://forum.djangoproject.com/c/internals/5 . Better to post there 
in future, or you could even duplicate this post.

I think your approach is worth sharing in a blog post, or even a package, 
rather than adding to Django itself.  Your code is worth sharing but may be too 
specific for the framework.

Unmanaged models aren’t particularly popular. When they are used, it can be for 
many reasons. As a result, projects may create the tables in various ways 
during tests, such as loading an existing database dump or calling an external 
tool. So using Django’s migrations to create them (through managed=True or 
SchemaEditor) is just one option among many.

By the way, you may be able to simplify your implementation with the new 
context methods in unittest from Python 3.11: 
https://adamj.eu/tech/2022/11/14/unittest-context-methods-python-3-11-backports/
 .

Thank you for sharing, and welcome to the Django community!

On Sun, Jan 28, 2024, at 11:00 PM, Emmanuel Katchy wrote:
> Hi everyone!
> 
> I'd like to get your thoughts on something.
> 
> Unmanaged models mean that Django no longer handles creating and managing 
> schema at the database level (hence the name).
> When running tests, this means these tables aren't created, and we can't run 
> queries against that model. The general solution I found is to monkey-patch 
> the TestSuiteRunner to temporarily treat models as managed 
> .
> 
> Doing a bit of research I however came up with a solution using SchemaEditor 
> , to create the 
> model tables directly, viz:
> 
> ```
> """
> A cleaner approach to temporarily creating unmanaged model db tables for tests
> """
> 
> from unittest import TestCase
> 
> from django.db import connections, models
> 
> class create_unmanaged_model_tables:
> """
> Create db tables for unmanaged models for tests
> Adapted from: https://stackoverflow.com/a/49800437
> Examples:
> with create_unmanaged_model_tables(UnmanagedModel):
> ...
> @create_unmanaged_model_tables(UnmanagedModel, FooModel)
> def test_generate_data():
> ...
> 
> @create_unmanaged_model_tables(UnmanagedModel, FooModel)
> def MyTestCase(unittest.TestCase):
> ...
> """
> 
> def __init__(self, unmanaged_models: list[ModelBase], db_alias: str = 
> "default"):
> """
> :param str db_alias: Name of the database to connect to, defaults to 
> "default"
> """
> self.unmanaged_models = unmanaged_models
> self.db_alias = db_alias
> self.connection = connections[db_alias]
> 
> def __call__(self, obj):
> if issubclass(obj, TestCase):
> return self.decorate_class(obj)
> return self.decorate_callable(obj)
> 
> def __enter__(self):
> self.start()
> 
> def __exit__(self, exc_type, exc_value, traceback):
> self.stop()
> 
> def start(self):
> with self.connection.schema_editor() as schema_editor:
> for model in self.unmanaged_models:
> schema_editor.create_model(model)
> 
> if (
> model._meta.db_table
> not in self.connection.introspection.table_names()
> ):
> raise ValueError(
> "Table `{table_name}` is missing in test 
> database.".format(
> table_name=model._meta.db_table
> )
> )
> 
> def stop(self):
> with self.connection.schema_editor() as schema_editor:
> for model in self.unmanaged_models:
> schema_editor.delete_model(model)
> 
> def copy(self):
> return self.__class__(
> unmanaged_models=self.unmanaged_models, db_alias=self.db_alias
> )
> 
> def decorate_class(self, klass):
> # Modify setUpClass and tearDownClass
> orig_setUpClass = klass.setUpClass
> orig_tearDownClass = klass.tearDownClass
> 
> @classmethod
> def setUpClass(cls):
> self.start()
> if orig_setUpClass is not None:
> orig_setUpClass()
> 
> 
> @classmethod
> def tearDownClass(cls):
> if orig_tearDownClass is not None:
> orig_tearDownClass()
> self.stop()
> 
> klass.setUpClass = setUpClass
> klass.tearDownClass = tearDownClass
> 
> return klass
> 
> def decorate_callable(self, callable_obj):
> @functools.wraps(callable_obj)
> def wrapper(*args, **kwargs):
> with self.copy():
> return callable_obj(*args, **kwargs)
> 
> return 

Re: Fellow Reports - January 2024

[Mariusz Felisiak]

Week ending February 4

*Triaged:*
https://code.djangoproject.com/ticket/35153 - FORMAT_MODULE_PATH not 
acting as I expected. (accepted)
https://code.djangoproject.com/ticket/35154 - QuerySet implements 
`contains` but not `__contains__` (wontfix)
https://code.djangoproject.com/ticket/35155 - Internal 500 error when 
deleting company model on production server (invalid)
https://code.djangoproject.com/ticket/35157 - "AttributeError: 
'QuerySet' object has no attribute 'copy'" combining FilteredRelation with 
subquery (duplicate)
https://code.djangoproject.com/ticket/35159 - dumpdata crashes on 
querysets with prefetch_related(). (accepted)
https://code.djangoproject.com/ticket/35160 - m2m_changed not trigerred 
when ManyToManyField in autocomplete list (needsinfo)
https://code.djangoproject.com/ticket/35163 - sqlite3.OperationalError: 
no such column: django_migrations.id (worksforme)
https://code.djangoproject.com/ticket/35162 - Adding a BinaryField, 
TextField, JSONField, or GeometryField with a db_default crashes on MySQL 
(accepted)
https://code.djangoproject.com/ticket/35164 - PermissionError: 
Permission denied: site-packages (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/17788 - [5.0.x] Updated 
translations from Transifex.
https://github.com/django/django/pull/1 - Refs #35058 -- Added 
support for measured geometries to GDAL LineString.
https://github.com/django/django/pull/17725 - Fixed #24128 -- Made 
admindocs TemplateDetailView respect template_loaders.
https://github.com/django/django/pull/17776 - Fixed #35141 -- Clarified 
the expected type of CACHE_MIDDLEWARE_SECONDS setting.
https://github.com/django/django/pull/17771 - Fixed #35135 -- Made 
FilteredRelation raise ValueError on querysets as rhs.
https://github.com/django/django/pull/17764 - Corrected 
BaseCommand.check() signature in docs.
https://github.com/django/django/pull/17760 - Fixed #29280 -- Made the 
transactions behavior configurable on SQLite.
https://github.com/django/django/pull/17796 - Made cosmetic edits to 
rocket SVG in the "Congrats" page.
https://github.com/django/django/pull/17787 - Fixed #35143 -- Improved 
accessibility of 404/500 debug pages.
https://github.com/django/django/pull/17800 - Refs #35058 -- Added 
support for measured geometries to GDAL Polygon.
https://github.com/django/django/pull/17803 - Fixed #35156 -- Removed 
outdated note about not supporting foreign keys by SQLite.
https://github.com/django/django/pull/17794 - Fixed #35152 -- Added 
en_CA locale formats.
https://github.com/django/django/pull/17783 - Removed mention of 
designers in DTL design philosophy.
https://github.com/django/django/pull/17694 - Changed packing 
recommendation to use pyproject.toml in reusable apps docs.
https://github.com/django/django/pull/17795 - Fixed #35147 -- Added 
backward incompatibility note about filtering against overflowing integers.
https://github.com/django/code.djangoproject.com/pull/171 - Used a 
plain HTML form for DjangoProject login.
https://github.com/django/django/pull/17817 - Fixed #35162 -- Fixed a 
crash when adding fields with db_default on MySQL.
https://github.com/django/django/pull/17813 - Fixed #35149 -- Fixed 
crashes of db_default with unresolvable output field.

*Authored:*
https://github.com/django/django/pull/17801 - Fixed #35159 -- Fixed 
dumpdata crash when base querysets use prefetch_related().

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5fa47be2-aabf-4377-abf3-7ace274d417cn%40googlegroups.com.

Re: Fellow Reports - January 2024

[Mariusz Felisiak]

Week ending January 28

*Triaged:*
https://code.djangoproject.com/ticket/35132 - Django admin dark mode 
leaves the main container light. (worksforme)
https://code.djangoproject.com/ticket/35134 - "Select all" checkbox in 
admin model view doesn't work in Django 5.0.1 (worksforme)
https://code.djangoproject.com/ticket/35133 - Make @method_decorator to 
work with async methods. (duplicate)
https://code.djangoproject.com/ticket/35130 - Document how to manually 
close database connections (accepted)
https://code.djangoproject.com/ticket/35135 - FilteredRelation fails 
when rhs of the condition is a queryset (accepted)
https://code.djangoproject.com/ticket/35139 - Performing a save() with 
an ImageField where width_field or height_field is set results in an extra 
read operation  (duplicate)
https://code.djangoproject.com/ticket/35141 - CACHE_MIDDLEWARE_SECONDS 
can be set to a float but has to be an int (accepted)
https://code.djangoproject.com/ticket/35143 - Improve accessibility of 
error page(s) with semantic HTML (accepted)
https://code.djangoproject.com/ticket/35142 - DATE and DATETIME 
settings have no effect since USE_L10N was deprecated (needsinfo)
https://code.djangoproject.com/ticket/35144 - Inconsistency in 
apostrophe symbols of translatable strings. And broken translations 
(invalid)
https://code.djangoproject.com/ticket/35145 - Django admin’s dark theme 
should set color-scheme property for vanilla HTML components (accepted)
https://code.djangoproject.com/ticket/35148 - Missed request cleanup 
for async views (duplicate)

*Reviewed/committed:*
https://github.com/django/django/pull/17680 - Fixed tutorial 
'background.gif' reference.
https://github.com/django/django/pull/17761 - Added more WKT and WKB 
tests.
https://github.com/django/djangoproject.com/pull/1462 - Fixed favicon 
URLs in search description.
https://github.com/django/django/pull/17766 - Fixed #35130 -- Doc'd 
django.db.close_old_connections().
https://github.com/django/code.djangoproject.com/pull/149 - JS cleanups.
https://github.com/django/django/pull/17768 - Refs #35058 -- Deprecated 
OGRGeometry.coord_dim setter.
https://github.com/django/django/pull/17769 - Refs #33517 -- Prevented 
__second lookup from returning fractional seconds on Oracle.
https://github.com/django/django/pull/17747 - Fixed #32923 -- 
Refactored out Field._clean_bound_field().
https://github.com/django/code.djangoproject.com/pull/146 - Update trac 
1.4.4.
https://github.com/django/django/pull/17774 - Fixed #35115 -- Made 
admin's footer render in  tag.
https://github.com/django/code.djangoproject.com/pull/155 - Fixed #151 
-- Fixed styling issues on ticket detail page.
https://github.com/django/code.djangoproject.com/pull/158 - Fixed 
leftover genshi syntax in template.
https://github.com/django/code.djangoproject.com/pull/156 - Link to the 
proper favicon.
https://github.com/django/django/pull/17696 - Refs #35058 -- Added 
support for measured geometries to GDAL Point.
https://github.com/django/code.djangoproject.com/pull/166 - Some more 
fixes in trackhacks.css.
https://github.com/django/django/pull/17782 - Updated Python license 
for 2024.
https://github.com/django/code.djangoproject.com/pull/167 - Fix 
spamfilter admin configuration page.
https://github.com/django/code.djangoproject.com/pull/168 - Fixed 
login/logout/logged as items in metanav.
https://github.com/django/django/pull/17786 - Refs #35058 -- Made 
centroid available on all geometry types.


*Authored:*https://github.com/django/code.djangoproject.com/pull/160 - 
Fixed #159 -- Used TracSpamFilter compatible with 1.4.
https://github.com/django/django/pull/17778 - Applied Black's 2024 
stable style.
https://github.com/django/django/pull/17779 - Bumped versions in Github 
actions configuration.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a5c50663-50e2-44d1-a03e-ab44b8a579e5n%40googlegroups.com.

Re: Possible async view regression in django 5.0?

[Natalia Bidart]

Hello Hugo, thanks for this email.

Just for completeness sake and for future readers, I'm leaving a note here
that a ticket was created for this issue (
https://code.djangoproject.com/ticket/35148) which was closed as a
duplicate of https://code.djangoproject.com/ticket/35059.

On Sun, Jan 28, 2024 at 9:23 PM Hugo Heyman  wrote:

> Hello!
>
> I've been troubleshooting an issue with lingering idle db connections
> (postgres) since upgrading from django 4.2 to 5.0. The issue manifested by
> db raising OperationalError FATAL: sorry, too many clients already not long
> after deploying the new version. We're running asgi with uvicorn + gunicorn.
>
> After extensive troubleshooting I installed django from a local repo and
> ran a git bisect to pin down the commit where this first occurred and ended
> up on this commit
> https://github.com/django/django/commit/64cea1e48f285ea2162c669208d95188b32bbc82
>
> Since I've recently built something quite async heavy I decided to dig
> into how the ASGIHandler code works and see if I can understand it and
> possibly make a fix if there really is some issue there.
>
> Now for the possible regression with django:
>
> The change introduced in Django 5.0 to allow handling of
> asyncio.CancelledError in views seems to also allow async views with normal
> HttpResponse handling client disconnects. As a consequence though the
> request_finished signal may not run leading to db connection not being
> closed.
>
> What currently seems to be happening in ASGIHandler in
> django/core/handlers/asgi.py goes something like this:
>
> 1. Concurrent tasks are started for
>   - disconnect listener (listen for "http.disconnect" from webserver)
>   - process_request
> 2. If disconnect happens first (e.g. browser refresh) cancel() is run on
> process_request task and request_finished may not have been triggered
> 3. db connection for the request is not closed :(
>
> Here are the lines of code where all this happens, marked:
> https://github.com/django/django/blob/9c6d7b4a678b7bbc6a1a14420f686162ba9016f5/django/core/handlers/asgi.py#L191-L232
>
> Possible fix? I'm thinking only views that return a HTTPStreamingResponse
> would need to allow for cancellation cleanup handling via the view. If so
> response = await self.run_get_response(request) could run before and
> outside of any task so we could check response.streaming attribute and only
> run listen_for_disconnect task when there's a streaming response.
>
> I've made a patch to try the above out and it seems to fix the issues.
> https://github.com/HeyHugo/django/commit/e25a1525654e00dcd5b483689ef16e0dc74d32d1
>
> Here's a minimal setup to demonstrate the issue via print debugging:
> https://github.com/HeyHugo/django_async_issue
>
> (I have never found a real bug in django so I'm still having doubts :D)
>
> Best regards
> /Hugo
>
> --
> 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/4c7a761b-1420-4997-900f-b8f0d59f4f31n%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/CA%2BfOnFY0-3GEhi2k%3DLzL9AiD8acRuCTMKPR62fgyPMnrN%2B803g%40mail.gmail.com.

Re: Fellow Reports - January 2024

[Mariusz Felisiak]

Week ending January 21

*Triaged:*
https://code.djangoproject.com/ticket/35113 - Adding urls.py file while 
creating new app using startapp command (duplicate)
https://code.djangoproject.com/ticket/35114 - Create a tests directory 
instead of tests.py when a new app is created (wontfix)
https://code.djangoproject.com/ticket/35112 - Confusing animation of 
admin date picker buttons (accepted)
https://code.djangoproject.com/ticket/34613 - add support for 
Partitioned cookies (accepted)
https://code.djangoproject.com/ticket/35115 - Empty footer element in 
main section of admin layout (accepted)
https://code.djangoproject.com/ticket/35117 - Add support for Hectare 
unit to Area (accepted)
https://code.djangoproject.com/ticket/34961 - Add a max_length 
parameter to EmailValidator (wontfix)
https://code.djangoproject.com/ticket/24721 - Add "test extensions" 
(e.g. something similar to mail.outbox for messages) (duplicate)
https://code.djangoproject.com/ticket/35120 - Stack overflow in render 
method when many instances of included template (needsinfo)
https://code.djangoproject.com/ticket/35121 - Links in the admin should 
use the --link-fg color. (created)
https://code.djangoproject.com/ticket/35122 - --prune should take 
app_label into account then checking squashed migrations. (accepted)
https://code.djangoproject.com/ticket/35123 - Migrate prune for apps 
that are deleted (wontfix)
https://code.djangoproject.com/ticket/35126 - forms.NullBooleanField's 
validation logic is surprising (invalid)
https://code.djangoproject.com/ticket/35128 - Soft-deletion feature 
(duplicate)
https://code.djangoproject.com/ticket/35129 - Support customize 
ForeignKey DDL when db_constraint=False (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/17730 - Fixed #35102 -- Optimized 
Expression.identity and friends.
https://github.com/django/django/pull/17592 - Fixed #28344 -- Allowed 
customizing queryset in Model.refresh_from_db()/arefresh_from_db().
https://github.com/django/django/pull/17712 - Fixed #34949 -- Clarified 
when UniqueConstraints with include/nulls_distinct are not created.
https://github.com/django/django/pull/17737 - Fixed #35112 -- Removed 
previous/next month animation in admin calendar widget.
https://github.com/django/django/pull/17732 - Fixed #35111 -- Fixed 
compilation of DateField __in/__range rhs on SQLite and MySQL.
https://github.com/django/django/pull/17742 - Used more specific link 
to email backends in EMAIL_BACKEND docs.
https://github.com/django/django/pull/17740 - Improved --list-tags help 
text for check management command.
https://github.com/django/django/pull/17739 - Fixed #35117 -- Added 
support for the hectare unit in Area.
https://github.com/django/django/pull/17344 - Fixed #31700 -- Made 
makemigrations command display meaningful symbols for each operation.
https://github.com/django/django/pull/17745 - Refs #35058 -- Added 
is_3d and set_3d() to OGRGeometry.
https://github.com/django/django/pull/17751 - Fixed #35121 -- Corrected 
color for links in the admin.
https://github.com/django/django/pull/17744 - Fixed #34910 -- Improved 
color contrast for add/change icons in admin.
https://github.com/django/django/pull/17756 - Updated "Dive Into 
Python" links.

*Authored:*
https://github.com/django/code.djangoproject.com/pull/147 - Added black 
to GitHub actions.
https://github.com/django/django/pull/17752 - Corrected forms imports 
in forms_tests/tests/test_forms.py.
https://github.com/django/django/pull/17758 - Fixed #35127 -- Made 
Model.full_clean() ignore GeneratedFields.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2f484af3-afb1-4f7c-aaf6-9e73be6f0f7cn%40googlegroups.com.

Re: Transition Docs to Inline

[Thibaud Colas]

Hi Moshe,

Just so you know there are a lot more discussions about Django these days 
on the Django Forum  than this mailing 
list. There are also no such things as Django lords or a governing board :) 
The project is consensus-driven, so doesn’t require any specific seal of 
approval.

As a Django beginner I’d really like better support for IDEs with those 
"hover" features you mentioned – and I don’t see why we’d have to move the 
docs inline to do that. Why not add docstrings where they’re missing, in 
addition to the docs as they stand currently? Django is a big enough 
project that there’s room to provide docs in different ways for different 
needs, and it doesn’t change often enough that keeping docs in sync would 
be an issue. According to the Django Developers Survey in 2022 
, 80% of Django 
devs use an IDE that offers this "inline docs on hover" developer 
experience nicety.

Django does have plenty of docstrings like this already, so perhaps we can 
add concise ones where there’s none currently in the public API, rather 
than having a big documentation refactoring project. Something like this – 
would be a quick win to add a one-liner for ModelForm:

[image: modelform hover screenshot.png]

Cheers,

Thibaud




On Thursday 11 January 2024 at 17:32:28 UTC Jörg Breitbart wrote:

> I agree that the official Python docs are well maintained and achieve a 
> tough goal - the right balance of just replaying basic interface facts 
> on one side, or being overly prosaic on the other side. Nope, they are 
> well balanced giving enough of both extremes to get you going, place 
> repo code lookup links, and examples where needed.
>
> And Python properly fills the __doc__ attribute on almost every function 
> or class, which is a big relief in interactive testing sessions to 
> quickly grasp a rarely used detail not in your muscle memory.
>
> With Django thats mostly not possible, inspecting __doc__ or using 
> help(XY) does often not reveal any useful information.
>
> > So no, I'd be a strong -1 to any recommendation suggesting that
> > docstrings be used to clutter up the code.
>
> I dont see how informative docstrings can clutter code, they are 
> visually well separated from code bodies, and most editors ven allow to 
> fold them.
>
> The bigger issue I see with docstrings is, that they sometimes end up 
> being written too machine firendly, e.g. full of restructuredText 
> formatting, which hinders human reading to some degree, esp. if you 
> never used those formats yourself before.
>

-- 
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/babf5ef5-3269-4799-bbbe-8f2599d1bd8en%40googlegroups.com.

Re: Transition Docs to Inline

[Jörg Breitbart]

I agree that the official Python docs are well maintained and achieve a 
tough goal - the right balance of just replaying basic interface facts 
on one side, or being overly prosaic on the other side. Nope, they are 
well balanced giving enough of both extremes to get you going, place 
repo code lookup links, and examples where needed.


And Python properly fills the __doc__ attribute on almost every function 
or class, which is a big relief in interactive testing sessions to 
quickly grasp a rarely used detail not in your muscle memory.


With Django thats mostly not possible, inspecting __doc__ or using 
help(XY) does often not reveal any useful information.


> So no, I'd be a strong -1 to any recommendation suggesting that
> docstrings be used to clutter up the code.

I dont see how informative docstrings can clutter code, they are 
visually well separated from code bodies, and most editors ven allow to 
fold them.


The bigger issue I see with docstrings is, that they sometimes end up 
being written too machine firendly, e.g. full of restructuredText 
formatting, which hinders human reading to some degree, esp. if you 
never used those formats yourself before.


--
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/050016b3-7cb8-4f23-b389-819aa1663f12%40netzkolchose.de.

Re: Transition Docs to Inline

[Ken Whitesell]

On 1/11/2024 12:01 AM, Moshe Dicker wrote:

I should not that I'm only being critical to improve.
The docs are well written, it's just disorganized.


Something I've learned over the past 47 years of reading computer 
documentation is that _no_ documentation is "perfect" - especially not 
for everyone.


All documentation is a compromise.

Different people have different ways of reading and understanding 
written material. There is no "one right way" to write or organize a set 
of manuals. The best you can hope for is to create docs that are 
complete, materially correct, and internally consistent.


I have also learned through the years that it's _me_ that needs to adapt 
myself to the different styles of documentation available. Yes, I have 
preferences for certain styles. But, I also recognize that not everyone 
reads and processes information the same way I do. I have no doubt that 
_you_ would find it an improvement to change the docs as you describe. 
However, I would suggest that you not try to sell the idea as being 
objectively true for everyone and that it's "obviously better".


Me? Personally, I have an extreme dislike of docs embedded in code. When 
I want to read the code, I want to see the code - not a full set of 
reference information that I have to wade through - and ignore - while 
I'm trying to find the information I want to see.


I want the code to be free of any clutter that can be better stored 
elsewhere.


Likewise, I greatly prefer docs that go well beyond just being an "API 
reference". I find sites for libraries showing nothing more than 
Javadoc-style pages to be virtually useless to me when I'm first getting 
started.


I have long maintained that I am more than twice as productive using 
Python than I am in any other language - and part of that is the quality 
of the Python docs. I always seem to be able to easily find what I'm 
looking for.


In my opinion, the Django docs are close - but not quite as good - as 
the Python docs. There are a couple of specific topics where I do find 
myself thinking "Where is that documented?" and have to search for it. 
It's not that I think they're in the "wrong" place, but it's probably 
not where _I_ would have put that information. But that's ok, I probably 
should just bookmark those pages...


So no, I'd be a strong -1 to any recommendation suggesting that 
docstrings be used to clutter up the code.



--
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/fcf2a34e-fb7c-4b9f-af73-6096c324af3c%40comcast.net.

Re: Transition Docs to Inline

[Moshe Dicker]

I should not that I'm only being critical to improve.
The docs are well written, it's just disorganized.
I mean no disrespect, we stand on the shoulders of giant, but that doesn't 
mean we should stop trying to improve. 
On Wednesday, January 10, 2024 at 11:57:40 PM UTC-5 Mariusz Felisiak wrote:

> Agreed with Tim.
>
> > *I'll argue that right now we don't have documentation. We just have a 
> mix of docs and reference, resulting in a convoluted manual that doesn't 
> fit either need.*
>
> This is a really unfair opinion (not the only one in your 
> comment). Hundreds of folks have put a lot of effort into making Django 
> documentation as great as it is today. It's one of our biggest advantages.
>
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ad6d6c73-4271-47b3-8aef-40988671fd15n%40googlegroups.com.

Re: Transition Docs to Inline

[Mariusz Felisiak]

Agreed with Tim.

> *I'll argue that right now we don't have documentation. We just have a 
mix of docs and reference, resulting in a convoluted manual that doesn't 
fit either need.*

This is a really unfair opinion (not the only one in your 
comment). Hundreds of folks have put a lot of effort into making Django 
documentation as great as it is today. It's one of our biggest advantages.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/58ef5d7c-d637-46ba-9811-2f4b74e65454n%40googlegroups.com.

Re: Transition Docs to Inline

[dickermo...@gmail.com]

I'll argue that right now we don't have documentation. We just have a mix of 
docs and reference, resulting in a convoluted manual that doesn't fit either 
need.
Django isn't some fly-by-night framework whose documentation will devolve if we 
move the technical reference and documentation into separate parts.
Looking at other packages for inspiration, fastapi and pydantic do great work 
of describing the technical parts and have a manual in a separate section.

Personally I would suggest moving the entire docs to mkdocs, with its better 
navigation. Although I understand that older frameworks are hesitant to change. 
I'll argue that right now we don't have documentation. We just have a mix of 
docs and reference, resulting in a convoluted manual that doesn't fit either 
need.
Django isn't some fly-by-night framework whose documentation will devolve if we 
move the technical reference and documentation into separate parts.
Looking at other packages for inspiration, fastapi and pydantic do great work 
of describing the technical parts and have a manual in a separate section.

Personally I would suggest moving the entire docs to mkdocs, with its better 
navigation. Although I understand that older frameworks are hesitant to change. 
From: Tim GrahamDate: Wed, Jan 10, 2024 5:41 
PMTo: Django developers  (Contributions to Django itself);Cc: Subject:Re: 
Transition Docs to Inline
I don't think moving docs inline is a good idea. Quoting Aymeric from 2013 
regarding django.contrib.admindocs [1] summarizes my feelings: 
"""
1) It's called the "documentation generator", but it only operates on 
docstrings. This promotes the idea that docstrings are appropriate 
documentation, while the Python and Django communities now favor prose 
documentation.



2) Even though it's possible to use docstrings to generate API 
documentation, for instance with Sphinx' autodoc, I find that heavily 
formatted, Javadoc-style docstrings (or late epydoc-style) tend to 
be hard to read for humans and I don't want Django to encourage them.
"""[1] 
https://groups.google.com/g/django-developers/c/0-qFyCPuSRs/m/kny7Oeu2RdoJOn 
Monday, January 8, 2024 at 11:55:19 AM UTC-5 Jörg Breitbart wrote:
Ah interesting that you mentioned django-stubs. I had good to mediocre 

success applying it to my own django apps. It gets the job mostly done 

for high level interfaces, but shows rough stub edges as soon as you 

have to touch lower interfaces (can only speak for the ORM section in 

this regard, which is highly mutating itself).



Type annotations in Python are heavily inspired by Typescript, where 

you'd strive for building up you interface types granularily and the 

compiler does the rest pulling things together.

I am not sure if Python's type annotations are yet or will ever be 

capable to achieve that good enough for most common python paradigm, 

seems Python is way too flexible for static type analysis. Typescript 

partially solves this by banning/hiding some of JS' flexibility. (Ever 

tried to fully type a mutating decorator in Python? Hours of fun ahead, 

and you will still end up declaring many Anys effectively disabling 

proper type pulling.)



Now back to Django - it makes heavy usage of dynamic python features, 

which is poison for any static type deduction. This is also the reason 

why IDEs typically fail for more dynamic python code like django, unless 

they do a partial runtime inspection (I think IntelliJ tries to do that 

to some degree).



So while better typing support is really nice where possible, I'd 

suggest to not open this can of worms (yet), but mainly to stick to the 

better inline docs idea.





Cheers,

Jörg





-- 

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/011ce3a2-3936-4e90-b205-5d12b229d536n%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/3l9as7b7scm3ihdkm38hg0m4.1704927306906%40email.lge.com.

Re: Transition Docs to Inline

[Tim Graham]

I don't think moving docs inline is a good idea. Quoting Aymeric from 2013 
regarding django.contrib.admindocs [1] summarizes my feelings: 
"""
1) It's called the "documentation generator", but it only operates on 
docstrings. This promotes the idea that docstrings are appropriate 
documentation, while the Python and Django communities now favor prose 
documentation. 

2) Even though it's possible to use docstrings to generate API 
documentation, for instance with Sphinx' autodoc, I find that heavily 
formatted, Javadoc-style docstrings (or late epydoc-style) tend to be hard 
to read for humans and I don't want Django to encourage them. 
"""
[1] 
https://groups.google.com/g/django-developers/c/0-qFyCPuSRs/m/kny7Oeu2RdoJ
On Monday, January 8, 2024 at 11:55:19 AM UTC-5 Jörg Breitbart wrote:

> Ah interesting that you mentioned django-stubs. I had good to mediocre 
> success applying it to my own django apps. It gets the job mostly done 
> for high level interfaces, but shows rough stub edges as soon as you 
> have to touch lower interfaces (can only speak for the ORM section in 
> this regard, which is highly mutating itself).
>
> Type annotations in Python are heavily inspired by Typescript, where 
> you'd strive for building up you interface types granularily and the 
> compiler does the rest pulling things together.
> I am not sure if Python's type annotations are yet or will ever be 
> capable to achieve that good enough for most common python paradigm, 
> seems Python is way too flexible for static type analysis. Typescript 
> partially solves this by banning/hiding some of JS' flexibility. (Ever 
> tried to fully type a mutating decorator in Python? Hours of fun ahead, 
> and you will still end up declaring many Anys effectively disabling 
> proper type pulling.)
>
> Now back to Django - it makes heavy usage of dynamic python features, 
> which is poison for any static type deduction. This is also the reason 
> why IDEs typically fail for more dynamic python code like django, unless 
> they do a partial runtime inspection (I think IntelliJ tries to do that 
> to some degree).
>
> So while better typing support is really nice where possible, I'd 
> suggest to not open this can of worms (yet), but mainly to stick to the 
> better inline docs idea.
>
>
> Cheers,
> Jörg
>

-- 
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/011ce3a2-3936-4e90-b205-5d12b229d536n%40googlegroups.com.

Re: Transition Docs to Inline

[Jörg Breitbart]

Ah interesting that you mentioned django-stubs. I had good to mediocre 
success applying it to my own django apps. It gets the job mostly done 
for high level interfaces, but shows rough stub edges as soon as you 
have to touch lower interfaces (can only speak for the ORM section in 
this regard, which is highly mutating itself).


Type annotations in Python are heavily inspired by Typescript, where 
you'd strive for building up you interface types granularily and the 
compiler does the rest pulling things together.
I am not sure if Python's type annotations are yet or will ever be 
capable to achieve that good enough for most common python paradigm, 
seems Python is way too flexible for static type analysis. Typescript 
partially solves this by banning/hiding some of JS' flexibility. (Ever 
tried to fully type a mutating decorator in Python? Hours of fun ahead, 
and you will still end up declaring many Anys effectively disabling 
proper type pulling.)


Now back to Django - it makes heavy usage of dynamic python features, 
which is poison for any static type deduction. This is also the reason 
why IDEs typically fail for more dynamic python code like django, unless 
they do a partial runtime inspection (I think IntelliJ tries to do that 
to some degree).


So while better typing support is really nice where possible, I'd 
suggest to not open this can of worms (yet), but mainly to stick to the 
better inline docs idea.



Cheers,
Jörg

--
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/b5d627ce-6460-476b-b90c-a9dec0350669%40netzkolchose.de.

Re: Transition Docs to Inline

[Moshe Dicker]

Django uses a lot of bootstrap/runtime patching under the hood, from custom 
metaclasses, explicit injection
pattern up to proxies at various ends.

I understand this is true on low level APIs and on classes we implement 
ourselves (Like passing the correct arguments when creating a django model).
But almost all the documentation in ref is connected to a class, function, 
method etc. This can be pushed into the source code and autodoced quite 
easily.
Anything that can’t be in a class can stay the way it is. Correct me if I’m 
wrong, It is almost certain that I am.
(Adding inline docs to django-stubs would help mitigate this, but 
coordinating documentation between 2 different projects would be a 
nightmare.)

I only see 2 downsides to my proposal:

   1. A big refactor to the codebase, There will be strings everywhere. 
   2. A larger install size.

​
On Sunday, January 7, 2024 at 8:53:44 PM UTC-5 Jörg Breitbart wrote:

> +1 on the idea for better inline docs, would be some relief for IDEs 
> figuring out a proper interface story boosting dev speed for rarely used 
> aspects, where currently one would have to search through the prosaic 
> online docs or end up browsing the django source.
>
> On the other hand I am not sure, if that an easy task to accomplish 
> without bigger refactoring. Django uses a lot of bootstrap/runtime 
> patching under the hood, from custom metaclasses, explicit injection 
> pattern up to proxies at various ends. Currently IDEs often give up 
> here, idk if more inline docs alone can change much or if the level of 
> abstraction within django would have to change to get a significant 
> improvement.
>
> Cheers,
> Jörg
>

-- 
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/6c56c8b8-0521-42e7-a7fd-98d66ea3c79en%40googlegroups.com.

Re: Transition Docs to Inline

[Jörg Breitbart]

+1 on the idea for better inline docs, would be some relief for IDEs 
figuring out a proper interface story boosting dev speed for rarely used 
aspects, where currently one would have to search through the prosaic 
online docs or end up browsing the django source.


On the other hand I am not sure, if that an easy task to accomplish 
without bigger refactoring. Django uses a lot of bootstrap/runtime 
patching under the hood, from custom metaclasses, explicit injection 
pattern up to proxies at various ends. Currently IDEs often give up 
here, idk if more inline docs alone can change much or if the level of 
abstraction within django would have to change to get a significant 
improvement.


Cheers,
Jörg

--
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/eea57151-576e-4b21-ae70-42a4e617565f%40netzkolchose.de.

Re: Transition Docs to Inline

[Moshe Dicker]

Django’s API Reference is more like a guide than an actual Reference at 
this point.
I’m proposing as follows: 

   1. We take any part of the reference that is short and to the point and 
   put it in a docstring.
   I think going the FastAPI route on this would be best, A guide and a 
   separate really robust API Reference that sources the technical info from 
   the docstrings. 
   Example: This 
   
,
 
   should be in the docstring of null.
   Implementation:class Foo: def __init__(self, value) -> None: """The Foo 
   class. :param value: "Simple string value" :type value: str """ 
   self.value = value foo = Foo(value="bar") 
   2. If this is rejected for whatever reason, can we please add just 
   docstring to link to the online docs.class Foo: def __init__(self, value) 
   -> None: """https://example.com""; self.value = value foo = Foo(value=
   "bar") 

​

I'm coming from Flutter where the documentation is pretty much only inline 
docs, It's really a pleasure to never need to lookup documentation.

This is a bunch of work. But having a lower barrier to entry is important. 
I think a docs refresh will really rock!

-- 
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/28393ec6-fb8c-4c3c-8f2a-55b56002ee42n%40googlegroups.com.

Re: Transition Docs to Inline

[Moshe Dicker]

I will address each part of your questions.

Why is consulting the online documentation insufficient? I think most 
developers build Django projects while referencing the online documentation 
rather than while reading Django’s source code. 

Having documentation available within the IDE really raises the developer 
experience.
For those with a Visual IDE it’s shown on hover, and even for those with a 
text editor they could see that docstring if they “click-into” the 
class/function/argument/parameter.

What sort of documentation would be inlined?

I will try to explain below how I think the separation of API Reference and 
Guides should be done.

Would this require a large amount of duplication between docs and source 
code?

God Forbid! Sphinx has autodoc which convert doctrings to reStructuredText. 

Why does adding docstrings require pyi files?

It isn’t required but it would help. I imagine that with some stub magic it 
would be possible to get docstrings applied onto a Meta class that doesn’t 
actually inherit anything
class CustomUser(models.Model): class Meta: 
< verbose_name = _("user") 

Are there other projects that use the approach you suggest?

Pretty much everything else.
Some mix docstrings and handwritten docs into 1 really nice API reference

   - FastAPI - API Reference (docs 
   |
   code 
   
)
 
   

Others write a regular guide separately, but generate API reference from 
docstrings

   - Flask - API Reference (docs 
   |code 
   

   ) 
   - Pydantic - API Reference (docs 
   |
   code 
   

   ) 

I could go on and on, but I’ve never come across a package that does not 
utilize docstrings at all.

Thanks!
​
On Friday, January 5, 2024 at 11:02:59 AM UTC-5 Tim Graham wrote:

> Hi Moshe, 
>
> Why is consulting the online documentation insufficient? I think most 
> developers build Django projects while referencing the online documentation 
> rather than while reading Django's source code.
>
> What sort of documentation would be inlined? Would this require a large 
> amount of duplication between docs and source code?
>
> Why does adding docstrings require pyi files? My text editor doesn't have 
> this "hover" feature. Please elaborate on your proposal for the 
> uninitiated. Are there other projects that use the approach you suggest?
> On Wednesday, January 3, 2024 at 2:38:02 PM UTC-5 Moshe Dicker wrote:
>
>> Due to the dynamic nature of Python, features aren’t obvious.
>> Developers don’t know what features a class has unless they dig through 
>> the convoluted source code themselves or going online to check the 
>> documentation.
>>
>> For example when implementing a `forms.ModelForm` hovering over it 
>> reveals absolutely nothing useful.
>>
>> [image: image]
>> image1000×157 11.5 KB
>>
>> 
>>
>> What do the “Django Lords” have to say about inlining the documentation 
>> in the source code itself.
>>
>> I know the “Django Lords” have been weary of adding type stubs.
>> However adding a docstring to this
>> ```
>> class Model(models.Model):
>> ...
>> class Meta: < THIS
>> ...
>> ```
>>
>> would require some stubs/.pyi files.
>>
>> I wouldn’t want to work on this just to find out that there are benefits 
>> of the current setup that they aren’t willing to make a tradeoff.
>>
>> What would be the best way of asking the Django Governing Board about 
>> their opinion on this?
>>
>

-- 
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/368ebda7-d776-4166-83de-9effa42fdb71n%40googlegroups.com.

Re: Transition Docs to Inline

[Tim Graham]

Hi Moshe, 

Why is consulting the online documentation insufficient? I think most 
developers build Django projects while referencing the online documentation 
rather than while reading Django's source code.

What sort of documentation would be inlined? Would this require a large 
amount of duplication between docs and source code?

Why does adding docstrings require pyi files? My text editor doesn't have 
this "hover" feature. Please elaborate on your proposal for the 
uninitiated. Are there other projects that use the approach you suggest?
On Wednesday, January 3, 2024 at 2:38:02 PM UTC-5 Moshe Dicker wrote:

> Due to the dynamic nature of Python, features aren’t obvious.
> Developers don’t know what features a class has unless they dig through 
> the convoluted source code themselves or going online to check the 
> documentation.
>
> For example when implementing a `forms.ModelForm` hovering over it reveals 
> absolutely nothing useful.
>
> [image: image]
> image1000×157 11.5 KB
>
> 
>
> What do the “Django Lords” have to say about inlining the documentation in 
> the source code itself.
>
> I know the “Django Lords” have been weary of adding type stubs.
> However adding a docstring to this
> ```
> class Model(models.Model):
> ...
> class Meta: < THIS
> ...
> ```
>
> would require some stubs/.pyi files.
>
> I wouldn’t want to work on this just to find out that there are benefits 
> of the current setup that they aren’t willing to make a tradeoff.
>
> What would be the best way of asking the Django Governing Board about 
> their opinion on this?
>

-- 
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/d079d602-a11d-46ae-86c0-4bee9a8ff01bn%40googlegroups.com.

Re: Fellow Reports - December 2023

[Mariusz Felisiak]

Week ending December 31


*Triaged:*https://code.djangoproject.com/ticket/35062 - Update csrf.py 
to check request.POST if request.method is not GET (invalid)
https://code.djangoproject.com/ticket/35059 - ASGI server leaves stale 
DB connections (needsinfo)
https://code.djangoproject.com/ticket/35064 - Window.order_by decimal 
field is broken on SQLite (accepted)
https://code.djangoproject.com/ticket/35065 - Autocomplete field is not 
rendered with error color border. (accepted)
https://code.djangoproject.com/ticket/35066 - Unsupported operand 
exception in response.py (invalid)
https://code.djangoproject.com/ticket/35067 - jsonb register (duplicate)
https://code.djangoproject.com/ticket/35068 - decimal as Float in 
settings (invalid)
https://code.djangoproject.com/ticket/35069 - Typo in Form.label_suffix 
example in docs. (accepted)
https://code.djangoproject.com/ticket/35070 - Default form output in 
docs is shown as as_table() instead of as_div() (invalid)
https://code.djangoproject.com/ticket/35075 - Add support for 
deduplicate_items option to BTreeIndex for PostgreSQL 13+. (accepted)
https://code.djangoproject.com/ticket/35072 - Model docs Field.choices 
inconsistency between reference and topic guide. (accepted)
https://code.djangoproject.com/ticket/35071 - Resolve lazy translation 
objects inside dictionaries when saving JSONFields (accepted)
https://code.djangoproject.com/ticket/35076 - improvement to the doc of 
ModelAdmin.view_on_site (invalid)


*Reviewed/committed:*https://github.com/django/django/pull/17637 - Refs 
#35058 -- Added __repr__() to OGRGeomType.
https://github.com/django/django/pull/17614 - Improved 
cache.tests.FileBasedCacheTests.test_touch to avoid flakiness due to slow 
file system access.
https://github.com/django/django/pull/17638 - Refs #35058 -- Made 
OGRGeomType aware of additional WKB geometry types.
https://github.com/django/django/pull/17610 - Improved 
DEFAULT_FROM_EMAIL/SERVER_EMAIL docs.
https://github.com/django/django/pull/17652 - Fixed #35065 -- Corrected 
border color for autocomplete fields with errors in admin.
https://github.com/django/django/pull/17653 - Removed unnecessary 
list() calls on sorted().
https://github.com/django/django/pull/17658 - Fixed #35064 -- Fixed 
Window(order_by) crash with DecimalFields on SQLite.
https://github.com/django/django/pull/17625 - Fixed #34670 -- Improved 
loading of theme in admin.
https://github.com/django/django/pull/17596 - Fixed #29049 -- Added 
slicing notation to F expressions.
https://github.com/django/django/pull/17661 - Fixed #35069 -- Fixed 
typo in docs/ref/forms/api.txt.
https://github.com/django/django/pull/17643 - Fixed #35051 -- Prevented 
runserver from removing non-zero Content-Length for HEAD requests.
https://github.com/django/django/pull/17664 - Used JSON_OBJECT database 
function on PostgreSQL 16+.


*Authored:*https://github.com/django/django/pull/17647 - Fixed #35056 
-- Fixed system check crash on reverse m2m relations with related_name in 
ModelAdmin.filter_horizontal/vertical.
https://github.com/django/django/pull/17648 - [3.2.x] Pinned 
python-memcached == 1.59 in test requirements.
https://github.com/django/django/pull/17651 - [5.0.x] Updated asgiref 
dependency for 5.0 release series.
https://github.com/django/django/pull/17654 - Corrected code-block 
directives in docs.
https://github.com/django/django/pull/17659 - Used addCleanup() in 
tests where appropriate.
https://github.com/django/code.djangoproject.com/pull/145 - Updated 
default ticket version to 5.0.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ccbc1dbf-f10d-458b-8f0d-a43b832ee8abn%40googlegroups.com.

Re: Fellow Reports - December 2023

[Mariusz Felisiak]

Week ending December 24

*Triaged:*
https://code.djangoproject.com/ticket/35046 - BlankChoiceIterator 
causes AttributeError for some existing packages and projects (invalid)
https://code.djangoproject.com/ticket/35050 - Issue filtering on 
FilteredRelation with F object (accepted)
https://code.djangoproject.com/ticket/35052 - Documentation corrections 
(invalid)
https://code.djangoproject.com/ticket/35053 - Limiting QuerySets is not 
database platform agnostic (duplicate)
https://code.djangoproject.com/ticket/35054 - Add support for oracledb 
2.0. (created)
https://code.djangoproject.com/ticket/35055 - `collectstatic` tries to 
parse commented out lines in CSS files. (duplicate)
https://code.djangoproject.com/ticket/35057 - Add a setting for project 
level callable/string for FileField's upload_to (wontfix)
https://code.djangoproject.com/ticket/35056 - admin.E013 on 
ManyToManyField with related_name crashes. (accepted)
https://code.djangoproject.com/ticket/35058 - Update GDAL integration 
(accepted)
https://code.djangoproject.com/ticket/35061 - Modifying GeneratedFields 
is not supported - not documented under model field reference for 
GeneratedField (wontfix)
https://code.djangoproject.com/ticket/35060 - Make Model.save() 
arguments keyword-only (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/16650 - Fixed #34411 -- Updated 
GDAL API to handle vector DataSource's.
https://github.com/django/django/pull/17582 - Fixed #35015 -- Updated 
MySQL notes in migrations topic.
https://github.com/django/django/pull/17628 Fixed #35048 -- Dropped 
support for PROJ 5.x.
https://github.com/django/django/pull/17627 - Fixed #35049 -- Dropped 
support for GDAL 2.4.
https://github.com/django/djangoproject.com/pull/1455 - Used formatted 
text for ongoing business in DSF meeting minutes.
https://github.com/django/django/pull/17629 - Fixed #35005 -- Confirmed 
support for GDAL 3.8.
https://github.com/django/django/pull/17631 - Fixed #35008 -- Added CSS 
rule for  HTML tags with no type.
https://github.com/django/django/pull/17626 - Fixed #34658 -- Added 
SimpleTestCase.assertNotInHTML().
https://github.com/django/django/pull/17635 - Fixed #35022 -- Fixed 
RenameIndex() crash on unnamed indexes if exists unique constraint on the 
same fields.
https://github.com/django/django/pull/17636 - Refs #35058 -- Added 
support for WKB > 2GB with GDAL 3.3+.
https://github.com/django/django/pull/17634 - Fixed #35050 -- Fixed 
prefixing field names in FilteredRelation().

*Authored:*
https://github.com/django/django/pull/17630 - Fixed #35054 -- Fixed 
crash on Oracle when fetching JSONFields with oracledb 2.0.0.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cd6c22e2-fb45-4c2e-ad4b-5306d0fa74dcn%40googlegroups.com.

Re: Deprecate CICharField, CIEmailField, CITextField

[Matthew Graham]

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

Re: Deprecate CICharField, CIEmailField, CITextField

[gw...@fusionbox.com]

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

Re: Add a PersistedTemporaryFileUploadHandler for file upload

[Jörg Breitbart]

My first reflex to this is -1 for a simple reason:

the persistence layer in django is meant to be db-driven. The upload 
logic is transient for that reason, and nothing stops you from creating 
a better controlled file upload handling with a model holding those 
files before entering your real business logic.


Adding another low-level persistent layer will create a lot of fuzz, 
esp. around the right way to evict those entries later on. And ppl will 
forget to delete those entries, if they are in doubt. Not a good idea.


--
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/fa54bd5c-0cb4-443c-8e90-fb1356adf339%40netzkolchose.de.

Re: Fellow Reports - November 2023

[Mariusz Felisiak]

Week ending November 26

*Triaged:*
https://code.djangoproject.com/ticket/34977 - Turn link to change 
password form in admin user change form into a button (accepted)
https://code.djangoproject.com/ticket/34978 - Annotating through an 
aggregate with RawSQL() raises 1056 "Can't group on" on MySQL/MariaDB. 
(accepted)
https://code.djangoproject.com/ticket/34980 - Changed migration 
operation dependencies to namedtuples. (created)
https://code.djangoproject.com/ticket/14810 - Admin inline templates 
need blocks (wontfix)
https://code.djangoproject.com/ticket/34982 - Visual regression for 
helptext with RTL languages. (created)
https://code.djangoproject.com/ticket/34986 - Fix up support for PyPy 
3.10 (accepted)
https://code.djangoproject.com/ticket/34983 - Deprecate 
django.utils.itercompat.is_iterable(). (accepted)
https://code.djangoproject.com/ticket/34985 - Migrations raise 
AppRegistryNotReady when GeneratedField references incorrect fields. 
(accepted)
https://code.djangoproject.com/ticket/34989 - Set Content-Length where 
possible for HttpResponses. (accepted)
https://code.djangoproject.com/ticket/34990 - Change external link for 
CSRF reference docs to OWASP (accepted)
https://code.djangoproject.com/ticket/34991 - Wrong layout of 
pagination buttons with editable list in the admin. (accepted)
https://code.djangoproject.com/ticket/34993 - Unexpected behaviour when 
filtering across mult-value (aka tomany) joins. (duplicate)
https://code.djangoproject.com/ticket/34994 - Visual regression in 
admin checkboxes on mobile (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/17491 - Refs #31026 -- Simplified 
BaseForm.get_context().
https://github.com/django/django/pull/17485 - Added VoiceOver iOS and 
macOS separately in admin FAQ.
https://github.com/django/django/pull/17505 - Fixed #34984 -- Skipped 
GeneratedFields when remaking tables on SQLite.
https://github.com/django/django/pull/17512 - Fixed #34990 -- Changed 
link to OWASP in CSRF docs.
https://github.com/django/django/pull/17511 - Fixed #34987 -- Fixed 
queryset crash when mixing aggregate and window annotations.
https://github.com/django/django/pull/17447 - Fixed #14611 -- Added 
query_params argument to RequestFactory and Client classes.
https://github.com/django/django/pull/17510 - Fixed #26827 -- Improved 
ModelState error message when relations refer model classes.
https://github.com/django/django/pull/17305 - Fixed #34818 -- Prevented 
GenericIPAddressField from mutating error messages.
https://github.com/django/django/pull/17498 - Fixed #34983 -- 
Deprecated django.utils.itercompat.is_iterable().
https://github.com/django/django/pull/17463 - Fixed #34968 -- Made 
multipart parsing of headers raise an error on too long headers.
https://github.com/django/django/pull/17417 - Fixed #34925 -- Prevented 
Model.refresh_from_db() from mutating list of fields.
https://github.com/django/django/pull/17526 - Refs #34925 -- Avoided 
altering passed by reference refresh_from_db(fields).
https://github.com/django/django/pull/17525 - Refs #34380 -- Improved 
docs for forms.URLField.assume_scheme.

*Authored:*
https://github.com/django/django/pull/17494 - Fixed #34980 -- Changed 
migration operation dependencies to namedtuples.
https://github.com/django/django/pull/17495 - Refs #34900 -- Added 
Python 3.13 to daily builds.
https://github.com/django/django/pull/17497 - Refs #34900 -- Skipped 
argon2-cffi requirement on daily builds for Python 3.13.
https://github.com/django/django/pull/17499 - Added PyPy 3.10 to daily 
builds.
https://github.com/django/django/pull/17503 - Refs #34900 -- Skipped 
Selenium requirement on daily builds for Python 3.13.
https://github.com/django/django/pull/17504 - Refs #34986 -- Installed 
libmemcached-dev in PyPy 3.10 daily builds.
https://github.com/django/django/pull/17506 - Fixed #34985 -- Fixed 
GeneratedFields.contribute_to_class() crash when apps are not populated.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4837137-8233-4dc5-a5dc-c730a4fc04cbn%40googlegroups.com.

Re: Looking for a code that separates fields while applying migrations

[Michiel Beijen]

On 28 Nov 2023, at 13:00, Remy Lukoo Hangi  wrote:
> 
> Fais-moi le setup.exe de python django suis débutant
> 

Hi Remy,

You found the developers email list for Django. Actually the email lists are 
not really used anymore, and you should use the ‘forums’ instead —> 
https://forum.djangoproject.com/c/users/6

However, there is no ‘setup.exe’ for Django, it does not really work that way. 
You’d be best off by reading the documentation here closely:
https://docs.djangoproject.com/en/4.2/intro/install/

Django is regarded as having good documentation and a comprehensive tutorial.

I hope this helps,

—
Michiel

-- 
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/C1B2781F-0374-4B72-87FA-324B33343C8C%40x14.nl.

Re: Looking for a code that separates fields while applying migrations

[Remy Lukoo Hangi]

Fais-moi le setup.exe de python django suis débutant

Le mardi 3 octobre 2023 à 06:41:12 UTC+2, Akash Sen a écrit :

> This one worked :   SQL: 
> https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/models/fields/__init__.py#L142
>  .
> Thank you Adam.
>
> On Monday, October 2, 2023 at 3:44:34 PM UTC+5:30 Adam Johnson wrote:
>
>> See alte_field in the schema editor: 
>> https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/backends/base/schema.py#L811
>>
>> It steps through what has changed in the field and generates SQL for the 
>> database relevant changes, queueing up statements with self.execute. Any 
>> non-SQL changes are basically ignored.
>>
>> Field.non_db_attrs tracks the field attributes rhat don’t affect SQL: 
>> https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/models/fields/__init__.py#L142
>>  . 
>> Note they may be modified by field subclasses, such as inDjango-MySQL’s 
>> EnumField.
>>
>> On Sat, Sep 30, 2023, at 3:57 PM, Akash Sen wrote:
>>
>> Hello everyone,
>> There are certain attributes in a field, after changing these the 
>> migration generated willbe applied to database, (for example take 
>> foreignkey) like null=True or db_default=1. As they have something to do 
>> with the database column.
>> There are some other attributes after changing these the migration 
>> generated will not be applied to database, like on_delete. As currently 
>> they have nothing to do with the database column.
>> In search of the code that takes care of that. Some help would be great!
>>
>>
>> -- 
>> 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/12539052-6e21-491a-b79e-e63edf451165n%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/b624ee4c-e081-47c7-a227-7fe17e80d46en%40googlegroups.com.

Re: Fellow Reports - October 2023

[Mariusz Felisiak]

Week ending November 3

Released Django 4.2.7, 4.1.13, and 3.2.23.

*Triaged:*
https://code.djangoproject.com/ticket/34941 - db_default with 
decimal.Decimal() doesn't return Decimal instances on Oracle. (created)
https://code.djangoproject.com/ticket/34943 - Support passing database 
expressions to bulk_create()'s unique_fields. (accepted)
https://code.djangoproject.com/ticket/34936 - db_default with 
decimal.Decimal() crashes on SQLite. (created)
https://code.djangoproject.com/ticket/34938 - Allow string based 
generators for AutoField (duplicate)

*Reviewed/committed:*
https://github.com/django/django/pull/17435 - Fixed #34927 -- Fixed 
admin system check for inlines with foreign keys to proxy models.
https://github.com/django/django/pull/17437 - Refs #31300 -- Allowed 
testing GeneratedField without collation.
https://github.com/django/django/pull/17427 - Fixed #34936 -- Fixed 
migration crash for DecimalField with db_default on SQLite.
https://github.com/django/django/pull/17415 - Fixed #34932 -- Restored 
varchar_pattern_ops/text_pattern_ops index creation when deterministic 
collaction is set.
https://github.com/django/django/pull/17423 - Refs #29850 -- Added 
exclusion support to window frames.
https://github.com/django/django/pull/17414 - Fixed #32106 -- Preserved 
HTTP_HOST in test Client when following redirects.
https://github.com/django/django/pull/17432 - Refs #34462 -- Moved 
ModelAdmin.log_deletion() test to a separate test case.
https://github.com/django/django/pull/16792 - Fixed #34462 -- Made 
admin log actions in bulk.

*Reviewed:*
https://github.com/django/django/pull/17428 - Refs #15578 -- Made 
cosmetic edits to fixtures docs.
https://github.com/django/django/pull/17429 - Refs #30601 -- Fixed 
typos in docs/topics/db/transactions.txt.

*Authored:*
https://github.com/django/django/pull/17440 - Refs #34941 -- Skipped 
OperationTests.test_alter_field_change_nullable_to_decimal_database_default_not_null
 
on Oracle.
https://github.com/django/django/pull/17441 - Fixed #34941 -- Fixed 
fetching decimal db_defaults for DecimalFields on Oracle.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0dffda5b-b21a-4200-8f60-6050e7e1e1dcn%40googlegroups.com.

Re: Fellow Reports - October 2023

[Mariusz Felisiak]

Week ending October 29

*Triaged:*
https://code.djangoproject.com/ticket/34923 - MESSAGE_TAGS ignored in 
5.0a1 (accepted)
https://code.djangoproject.com/ticket/34924 - Example for 
squashmigration not working properly (duplicate)
https://code.djangoproject.com/ticket/34919 - Missing scope attribute 
in admin doc table headers. (accepted)
https://code.djangoproject.com/ticket/34926 - Missing model after 
squashing (invalid)
https://code.djangoproject.com/ticket/34928 - makemigrations when 
adding a ForeignKey to a model with a UniqueConstraint must create the 
field before creating the constraint (duplicate)
https://code.djangoproject.com/ticket/34930 - Parallel tests fail on 
Python 3.11+ and MacOS. (needsinfo)
https://code.djangoproject.com/ticket/34931 - QuerySet .count() crashes 
when queryset contains FilteredRelation referencing annotation in condition 
(duplicate)
https://code.djangoproject.com/ticket/34932 - Setting deterministic 
Postgres collations incorrectly disallows use of varchar_pattern_ops and 
text_pattern_ops (accepted)
https://code.djangoproject.com/ticket/34917 - Links within text in the 
Django admin are difficult to identify (duplicate)
https://code.djangoproject.com/ticket/34934 - Made 
EmailValidator.__eq__() ignore domain_allowlist ordering. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/17373 - Fixed #34903, Refs #34825 
-- Made workers initialization respect empty set of used connections.
https://github.com/django/django/pull/17402 - Refs #34118 -- Avoided 
repeat coroutine checks in MiddlewareMixin.
https://github.com/django/django/pull/17398 - Fixed #34920 -- Made 
FileExtensionValidator.__eq__() ignore allowed_extensions ordering.
https://github.com/django/django/pull/17377 - Fixed #34904 -- Prevented 
mutating sent emails from outbox in locmem email backend.
https://github.com/django/django/pull/17392 - Fixed #27403 -- Doc'd 
that QuerySet.prefetch_related() doesn't guarantee transactional 
consistency.
https://github.com/django/django/pull/17368 - Fixed #10941 -- Added {% 
query_string %} template tag.
https://github.com/django/django/pull/17406 - Doc'd writing integration 
tests for the system check framework.
https://github.com/django/django/pull/17420 - Fixed #34943 -- Made 
EmailValidator.__eq__() ignore domain_allowlist ordering.
https://github.com/django/django/pull/17422 - Refs #29850 -- Added 
RowRange support for positive integer start and negative integer end.

*Reviewed:*
https://github.com/django/django/pull/17384 - Fixed #15578 -- Stated 
the processing order of fixtures in the fixtures docs.

*Authored:*
https://github.com/django/django/pull/17403 - Bumped versions in 
pre-commit and npm configurations.
https://github.com/django/django/pull/17407 - Fixed #34923 -- Avoided 
initializing LEVEL_TAGS when importing django.contrib.messages.
https://github.com/django/django/pull/17409 - Added missing pycon 
directives in various docs.
https://github.com/django/django/pull/17412 - Fixed isolation of 
DatabaseWrapperLoggingTests.test_commit_debug_log().

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/425abb0a-b1b7-4de7-a261-5534888f7cd1n%40googlegroups.com.

Re: How do you set the python path for django-admin?

[Carlton Gibson]

Hi tobias.

The django-admin command has a `--pythonpath` option for this (docs

).

So, for example in a 3rd party package using the src layout (example
) where the module itself is
installed in the venv, but the tests module is at the package root, you can
run the tests like:

django-admin test --settings=tests.settings --pythonpath=.

HTH.

Kind Regards,

Carlton

On Wed, 8 Nov 2023 at 20:18, Tobias Bengfort 
wrote:

> Hi everyone,
>
> https://docs.djangoproject.com/en/4.2/ref/django-admin/ claims that
> manage.py, django-admin and python -m django are practically
> interchangable. However, I noticed that they behave differently when it
> comes to the python path (the path you can import modules from). I used
> `CMD shell -c 'import sys; print(sys.path[0])' to check each one:
>
> - `manage.py` adds its own location to the python path. That is fine
> because `django-admin startproject` puts it right next to the project
> directory.
>
> - `django-admin` also adds its own location to the python path. That is
> less fine because that is usualy something like /some/venv/bin/, so the
> project package is not importable. Simply running `django-admin
> runserver --settings=example.settings` fails with `ModuleNotFoundError:
> No module named 'example'`.
>
> - `python -m django` uses the current directory, which is slightly less
> useful than manage.py, but quite intuitive.
>
> Of course you can circumvent all of this by setting PYTHONPATH explicitly.
>
> I personally was burned by this because I use `pip install -e` to add
> the folder containing the project directory to the python path. However,
> when switching to PEP 517 based packaging, the behavior changed and some
> modules could no longer be imported.
>
> is there any official recommendation about this? My impression was
> always that manage.py is meant for development and django-admin is meant
> for production. But how are you supposed to set the python path in that
> case? Is this assumption even correct? I could not find anything about
> it in the docs.
>
> In any case, I think the docs need an update because currently, all
> examples use `django-admin`, which does not work out of the box in my
> experience.
>
> thanks,
> tobias
>
> --
> 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/2b27a633-f658-4fe8-ab41-d553890b03c6%40posteo.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/CAJwKpyT2onzVkQ3MdGQR83uPxs_7GG5Zb%2BsZtzwy7gR1-6-aHA%40mail.gmail.com.

Re: Wrong ordering of many-to-many fields with explicit intermediary model in Django admin

[Mariusz Felisiak]

Hi Alan,

This is a known issue, you can find a discussion in 
https://code.djangoproject.com/ticket/12203. It's an accepted ticket so 
feel-free to work on it.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c8dcce28-3f24-42a3-b069-cb6a026bea31n%40googlegroups.com.

Re: Potential bug with how Value works with Django ORM queries

[Nitin Chaudhary]

Hi David,

Thanks for response. I understand it now. I was assuming that Value auto 
typecasts to the field that we are querying. This makes sense.
Thank you for taking time to respond.

Cheers
Nitin
On Thursday, October 26, 2023 at 3:52:17 AM UTC-4 David Sanders wrote:

> Hi Nitin,
>
> Not sure what db you're using but will explain assuming PG.
>
> In this particular example, Django uses the `->` operator which requires 
> that we compare jsonb types.  The `__in=("Program1", "Program2")` is 
> converted to jsonb via `DatabaseOperations.adapt_json_value()` where as 
> `Value()` isn't.
>
> `Value()` assumes the type of the argument passed in – in this case `str` 
> – unless you pass a second argument, `output_field`. Specifying 
> `output_field=JSONField()` will cause the ORM to pass these values to 
> `DatabaseOperations.adapt_json_value()`.
>
> So this will work:
>
> `Study.objects.filter(study_data__protocol__general__program_name__in=(Value("Program1",
>  
> output_field=JSONField()), ...))`
>
> Regards
> David
>
> On Thursday, 26 October 2023 at 03:39:08 UTC+11 Nitin Chaudhary wrote:
>
>> Hi 
>> I recently came across a very interesting scenario. I have a JSON Field 
>> which I want to query on. I was trying to do some performance 
>> optimizations  and came across this
>>
>> If I query a non-JSON field like this:
>> Study.objects.all().filter(study_id__in=[Value("Tes1"),Value("Test2")])
>> and 
>> Study.objects.all().filter(study_id__in=["Test1","Test2"])
>> both of these queries return the same results
>>
>> but if I try performing the same on a JSONField
>> Study.objects.all().filter(study_data__protocol__general__program_name__in=(Value("Program1"),
>>  
>> Value("Program2")))
>> results in
>> DataError: invalid input syntax for type json
>> LINE 1: ...> ARRAY['protocol','general','program_name']) IN ('Prog ...
>>  ^
>> DETAIL:  Token "Program1" is invalid.
>> CONTEXT:  JSON data, line 1: Program1
>>
>> and 
>>
>> Study.objects.all().filter(study_data__protocol__general__program_name__in=("Program1","Program2"))
>> works fine.
>>
>> I am not sure if this is a potential bug with Django or is like this by 
>> design. Would really appreciate if someone can explain this behavior 
>> difference.
>>
>> Cheers
>>
>>

-- 
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/ca7c9196-535f-4372-843e-82544fa6ed89n%40googlegroups.com.

Re: Potential bug with how Value works with Django ORM queries

[David Sanders]

Hi Nitin,

Not sure what db you're using but will explain assuming PG.

In this particular example, Django uses the `->` operator which requires 
that we compare jsonb types.  The `__in=("Program1", "Program2")` is 
converted to jsonb via `DatabaseOperations.adapt_json_value()` where as 
`Value()` isn't.

`Value()` assumes the type of the argument passed in – in this case `str` – 
unless you pass a second argument, `output_field`. Specifying 
`output_field=JSONField()` will cause the ORM to pass these values to 
`DatabaseOperations.adapt_json_value()`.

So this will work:

`Study.objects.filter(study_data__protocol__general__program_name__in=(Value("Program1",
 
output_field=JSONField()), ...))`

Regards
David

On Thursday, 26 October 2023 at 03:39:08 UTC+11 Nitin Chaudhary wrote:

> Hi 
> I recently came across a very interesting scenario. I have a JSON Field 
> which I want to query on. I was trying to do some performance 
> optimizations  and came across this
>
> If I query a non-JSON field like this:
> Study.objects.all().filter(study_id__in=[Value("Tes1"),Value("Test2")])
> and 
> Study.objects.all().filter(study_id__in=["Test1","Test2"])
> both of these queries return the same results
>
> but if I try performing the same on a JSONField
> Study.objects.all().filter(study_data__protocol__general__program_name__in=(Value("Program1"),
>  
> Value("Program2")))
> results in
> DataError: invalid input syntax for type json
> LINE 1: ...> ARRAY['protocol','general','program_name']) IN ('Prog ...
>  ^
> DETAIL:  Token "Program1" is invalid.
> CONTEXT:  JSON data, line 1: Program1
>
> and 
>
> Study.objects.all().filter(study_data__protocol__general__program_name__in=("Program1","Program2"))
> works fine.
>
> I am not sure if this is a potential bug with Django or is like this by 
> design. Would really appreciate if someone can explain this behavior 
> difference.
>
> Cheers
>
>

-- 
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/95511868-4a44-4757-a992-b4e17c716668n%40googlegroups.com.

Re: Question about support dates

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

As the maintainer of several Django-related packages and a contributor to many 
more, I see the policy as fair. Most maintainers have little capacity, and 
anything to reduce that burden is welcome.

Third-party packages typically test with a matrix of Python versions against 
Django versions. Letting that grow large makes writing code harder, testing 
slow, and wastes CI computing power and energy.

Users using Django 3.2 can still install and use old versions of third-party 
packages. Aside from data loss bugs or security issues, third-party packages 
dropping support for 3.2 to 4.1 will probably have little effect on such 
projects.

> Secondly, it would help me if end dates of both mainstream and extended 
> support were set to specific dates. This hold true for all end dates in the 
> release schedule on https://www.djangoproject.com/download/ .
> For example, the end date of extended for Django 5.1 ends either in December 
> 2025 or per 1st of January 2026, which is not clear to me. I believe this 
> difference to be relevant for organizations scheduling updates.

Django versions make one release per month (if there are any changes). This is 
typically the first Monday but depends on fellow availability and the state of 
any pull requests. That’s why there’s no date commitment. After any initial 
bugfix release date in the final month of release, it’s unlikely that any 
further drastic bugs will be discovered and backported to the branch.

Also, I have never encountered a Django project that upgrades within or near 
the final month of support. There are two camps: those who upgrade proactively 
(either to each release or LTS), and those who don’t (often found running a 
ten-year-old Django with custom backports). I doubt that a more concrete date 
would help with scheduling updates. If it helps get resources, assume the first 
of the month, or better yet push for margin and aim to upgrade 6 months before 
EOL.

On Wed, Oct 25, 2023, at 8:45 AM, Wim Feijen wrote:
> Hi,
> 
> The release notes of Django 5.0 state:
> "Third-party library support for older version of Django¶
> 
> Following the release of Django 5.0, we suggest that third-party app authors 
> drop support for all versions of Django prior to 4.2. At that time, you 
> should be able to run your package’s tests using python -Wd so that 
> deprecation warnings appear. After making the deprecation warning fixes, your 
> app should be compatible with Django 5.0."
> 
> However, Django 3.2 is supported until April 2024. Would it not be 
> recommendable for third-party packages to support Django 3.2 as well?
> 
> My proprosal is to remove the above warning entirely from the release notes, 
> or to change the first line to "From April 2024 on, we suggest that ..."
> 
> Secondly, it would help me if end dates of both mainstream and extended 
> support were set to specific dates. This hold true for all end dates in the 
> release schedule on https://www.djangoproject.com/download/ .
> For example, the end date of extended for Django 5.1 ends either in December 
> 2025 or per 1st of January 2026, which is not clear to me. I believe this 
> difference to be relevant for organizations scheduling updates.
> 
> Thanks for considering this, and for the awesome work on making Django better 
> and better!
> 
> Warm regards,
> Wim
> 
> 
> 
> -- 
> 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/38ace698-489b-4a66-86d6-bb755e932008n%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/29d8a725-3ea7-40f7-9cca-7aa4ad675224%40app.fastmail.com.

Re: Fellow Reports - October 2023

[Mariusz Felisiak]

Week ending October 22

*Triaged:*
https://code.djangoproject.com/ticket/34901 - Add async interface to 
contrib.sessions (accepted)
https://code.djangoproject.com/ticket/34902 - 
django.test.client.Client.head request fails on AttributeError as_sync is 
missing (worksforme)
https://code.djangoproject.com/ticket/34903 - Parallel test runner 
failure on Windows (accepted)
https://code.djangoproject.com/ticket/34904 - Changing email object 
after sending mutates mail in mail.outbox (accepted)
https://code.djangoproject.com/ticket/34905 - Main landmark is on the 
wrong element (accepted)
https://code.djangoproject.com/ticket/34906 - Need help with 
makemigrations (invalid)
https://code.djangoproject.com/ticket/34911 - Admindocs index skips 
from h1 to h3 (accepted)
https://code.djangoproject.com/ticket/34914 - Postgres connection is 
not restarted after it's dropped by the server, even if we use 
CONN_HEALTH_CHECKS=True (duplicate)
https://code.djangoproject.com/ticket/34915 - Do not autopopulate 
_order field for model with an order_with_respect_to if already set. 
(wontfix)
https://code.djangoproject.com/ticket/34916 - Add support for brotli 
compression (wontfix)
https://code.djangoproject.com/ticket/34907 - loaddata crashes on 
objects with natural keys when don't exist on passed database. (accepted)
https://code.djangoproject.com/ticket/34917 - Links within text in the 
Django admin are difficult to identify (wontfix)
https://code.djangoproject.com/ticket/34918 - Assigning model instance 
to `_id`/attname field saves correctly, but breaks accessing the field 
(invalid)
https://code.djangoproject.com/ticket/34920 - 
FileExtensionValidator.__eq__() should ignore allowed_extensions order. 
(accepted)
https://code.djangoproject.com/ticket/34921 - Filtering an unbound 
DateTimeField with naive date crashes (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/17369 - Fixed #34798 -- Fixed 
QuerySet.aggregate() crash when referencing expressions containing 
subqueries.
https://github.com/django/django/pull/17360 - Refs #34043 -- Added 
context managers to SeleniumTestCase for changing window size.
https://github.com/django/django/pull/17371 - Removed unreachable code 
from ModelAdmin.response_change().
https://github.com/django/django/pull/17374 - Refs #34043 -- Added 
--screenshots option to runtests.py and selenium tests.
https://github.com/django/django/pull/16963 - Refs #34043 -- Added 
GitHub action to capture screenshots in Selenium tests.
https://github.com/django/django/pull/17375 - Refs #34043 -- Tweaked 
wording in release note.
https://github.com/django/django/pull/17378 - Made 
SeleniumTests.test_select_multiple less flaky by improving Selenium waits.
https://github.com/django/django/pull/17382 - Fixed #34905 -- Corrected 
admin's main content element rendered in  tag.
https://github.com/django/django/pull/17385 - Fixed #34911 -- Corrected 
HTML heading levels on admindocs' main page.
https://github.com/django/django/pull/17386 - Fixed #34912 -- Fixed 
size of back links and bookmarklet help in admindocs pages.
https://github.com/django/django/pull/17390 - Restructured writing 
documentation contributing guide.
https://github.com/django/django/pull/17387 - Fixed #34913 -- Added 
borders on high contrast mode in the admin.
https://github.com/django/django/pull/17399 - Fixed #34921 -- Fixed 
crash of warning for unbound naive datetimes.

*Authored:*
https://github.com/django/django/pull/17380 - Fixed permissions for 
GitHub action with screenshots.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91e60282-ca0d-454d-9be4-f54f8084c0a8n%40googlegroups.com.

Re: Fellow Reports - October 2023

[Mariusz Felisiak]

Week ending October 15

*Triaged:*
https://code.djangoproject.com/ticket/34894 - Query.change_aliases() 
has several significant bugs (needsinfo)
https://code.djangoproject.com/ticket/34895 - Reverse migrations fail 
with mysql / mariadb with sql_safe_updates set to 1 (duplicate)
https://code.djangoproject.com/ticket/12075 - Add wsgiorg.routing args 
support (wontfix)
https://code.djangoproject.com/ticket/34898 - Adding non-deterministic 
collations to unique CharFields crashes on PostgreSQL. (accepted)
https://code.djangoproject.com/ticket/14761 - URL resolving / reversing 
design doesn't allow alternate specs (needsinfo)
https://code.djangoproject.com/ticket/34900 - Python 3.13 
compatibility. (someday/maybe)

*Reviewed/committed:*
https://github.com/django/django/pull/17349 - Refs #34043 -- Clarified 
how to test UI changes.
https://github.com/django/django/pull/17351 - [5.0.x] Refs #26029 -- 
Improved get_storage_class() deprecation warning with stacklevel=2.
https://github.com/django/django/pull/17194 - Fixed #12241 -- Preserved 
query strings when using "Save and continue/add another" in admin.
https://github.com/django/django/pull/17359 - Refs #34840 -- Improved 
release note describing index regression.

*Reviewed:*
https://github.com/django/django/pull/17308 - Fixed #34808 -- Doc'd 
aggregate default argument.

*Authored:*
https://github.com/django/django/pull/17348 - Added backticks to 
setuptools in docs.
https://github.com/django/django/pull/17354 - Refs #34882 -- Fixed 
GISFunctionsTests.test_asgeojson_option_0() test on Oracle.
https://github.com/django/asgiref/pull/414 - Dropped Python 3.7 support.
https://github.com/django/django/pull/17356 - Refs #34840 -- Fixed 
test_validate_nullable_textfield_with_isnull_true() on databases that don's 
support table check constraints.
https://github.com/django/asgiref/pull/412 - Added Python 3.12 support.
https://github.com/django/django/pull/17367 - Refs #34900, Refs #34118 
-- Updated assertion in test_skip_class_unless_db_feature() test on Python 
3.12.1+.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6093cc27-09e8-456e-a62d-4ecbf44c81e2n%40googlegroups.com.

Re: Admin login view does not respect REDIRECT_LOGIN_URL

[Maciek Olko]

Hello,

Please double check the setting name, it should be LOGIN_REDIRECT_URL
https://docs.djangoproject.com/en/4.2/ref/settings/#login-redirect-url.

Regards,
Maciej

wt., 17 paź 2023 o 05:35 Gagan Deep 
napisał(a):

> Hello everyone,
>
> While working on my project, I found that the admin login view does not
> respect the REDIRECT_LOGIN_URL
> .
> This could be design decision that I am overlooking (because admin is a
> special case?).
>
> In my limited time, I couldn't find a related discussion for this on
> Django's trac or GitHub repository (PRs). Hence, I wanted to confirm before
> opening a issue on trac.
>
> Regards,
> Gagan Deep
>
> --
> 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/6ead2cb4-c88f-4b4e-bd6c-a531491454cdn%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/CALYYG81Brg0QsioNMf-kVoTSw6VzaWPWxVyijGSnPTY4j-%3DJ-g%40mail.gmail.com.

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

[Akash Sen]

Got it. Thank you for the response Mariusz and Simon.

On Tuesday, October 17, 2023 at 11:43:00 AM UTC+5:30 Mariusz Felisiak wrote:

> I wanted to propose these solution as a hotfix unless we get #31202 
>  or #29771 
>  done. As we are 
> going to upgrade the bulk_update in near future, resolving the bug for now 
> seems reasonable to me.
>
>
> This is not a critical or security issue, we generally don't add 
> "hotfixes" to bugs. Moreover, temporarily changing signatures of existing 
> functions would be against our API stability policy. 
>

-- 
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/bfce41c1-b914-45d6-ac52-08f2e0f3a306n%40googlegroups.com.

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

[Mariusz Felisiak]

I wanted to propose these solution as a hotfix unless we get #31202 
 or #29771 
 done. As we are going 
to upgrade the bulk_update in near future, resolving the bug for now seems 
reasonable to me.


This is not a critical or security issue, we generally don't add "hotfixes" 
to bugs. Moreover, temporarily changing signatures of existing functions 
would be against our API stability policy. 

-- 
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/70924d73-bdb3-46bf-a50e-3331dd93c27an%40googlegroups.com.

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

[Akash Sen]

The argument of having new specialized bulk_update_cast method is more 
logical than the earlier two approaches. But the best approach should be 
drop using Case / When which will eventually come with #31202 
 or #29771 
. I wanted to propose 
these solution as a hotfix unless we get #31202 
 or #29771 
 done. As we are going 
to upgrade the bulk_update in near future, resolving the bug for now seems 
reasonable to me.
PS: Currently going through all the discussions for #31202 
 and #29771 
 as there are a lot of 
them, will try to propose a solution soon once the #21961 
 is closed.

*Regards,*
Akash Kumar Sen

LinkedIn  | GitHub 


On Tuesday, October 17, 2023 at 4:27:50 AM UTC+5:30 charettes wrote:

> Hello Akash,
>
> Another approach that isn't mentioned here but alluded to in the ticket 
>  is to actually 
> move bulk_update away from using Case / When which is the root of the issue 
> here.
>
> We know that using Case / When is slow 
>  and is the reason why we 
> need to perform casting in the first place 
> . While 
> knowing that there is complexity 
>  in doing so we 
> already have pointers on how to approach the problem 
>  and it was already 
> discussed in the past 
> 
> .
>
> I think that even if it requires a larger investment than adding a new 
> kwarg to Cast or have bulk_update call a new specialized bulk_update_cast 
> method on the backend instead of checking for the 
> requires_casted_case_in_updates 
> flag it should be a strongly considered option.
>
> Cheers,
> Simon
> Le lundi 16 octobre 2023 à 10:17:07 UTC-4, Akash Sen a écrit :
>
>> Ticket#33647 : bulk_update silently truncating values for size limited 
>> fields 
>>
>> *Approach 1:*
>> As mentioned by Simon in this comment 
>>  we can introduce 
>> a new argument maybe named  generic in the database function Cast similar 
>> to the following
>> Cast(expr, ArrayField(CharField(max_length=20), generic=True).
>> Although as mentioned by Mariusz in this comment 
>>  "we 
>> cannot introduce new keyword arguments into database function that will be 
>> only be used to fix usage elsewhere in the Django code."
>> But the explanation is still a little unclear to me, it would be great if 
>> someone can explain the reason.
>>
>> *Approach 2:*
>> As we will not be able to introduce a new new keyword arguments into 
>> database function we can create a new database function named something 
>> like GenericCast,That will cast according to the type only without 
>> specifying the maximum length.
>> And we will use this to the only line causing this regression in 
>> bulk_update, i.e : 
>> https://github.com/django/django/blob/a1e4e86f923dc8387b0a9c3025bdd5d096a6ebb8/django/db/models/query.py#L765
>>  
>> .
>>
>> I would like to move forward with the Approach 2. Some feedback would be 
>> great.
>>
>

-- 
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/ee2de40e-398c-47b1-ad33-c2be3947c47bn%40googlegroups.com.

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

[charettes]

Hello Akash,

Another approach that isn't mentioned here but alluded to in the ticket 
 is to actually move 
bulk_update away from using Case / When which is the root of the issue here.

We know that using Case / When is slow 
 and is the reason why we need 
to perform casting in the first place 
. While 
knowing that there is complexity 
 in doing so we 
already have pointers on how to approach the problem 
 and it was already discussed 
in the past 

.

I think that even if it requires a larger investment than adding a new 
kwarg to Cast or have bulk_update call a new specialized bulk_update_cast 
method on the backend instead of checking for the 
requires_casted_case_in_updates 
flag it should be a strongly considered option.

Cheers,
Simon
Le lundi 16 octobre 2023 à 10:17:07 UTC-4, Akash Sen a écrit :

> Ticket#33647 : bulk_update silently truncating values for size limited 
> fields 
>
> *Approach 1:*
> As mentioned by Simon in this comment 
>  we can introduce 
> a new argument maybe named  generic in the database function Cast similar 
> to the following
> Cast(expr, ArrayField(CharField(max_length=20), generic=True).
> Although as mentioned by Mariusz in this comment 
>  "we 
> cannot introduce new keyword arguments into database function that will be 
> only be used to fix usage elsewhere in the Django code."
> But the explanation is still a little unclear to me, it would be great if 
> someone can explain the reason.
>
> *Approach 2:*
> As we will not be able to introduce a new new keyword arguments into 
> database function we can create a new database function named something 
> like GenericCast,That will cast according to the type only without 
> specifying the maximum length.
> And we will use this to the only line causing this regression in 
> bulk_update, i.e : 
> https://github.com/django/django/blob/a1e4e86f923dc8387b0a9c3025bdd5d096a6ebb8/django/db/models/query.py#L765
>  
> .
>
> I would like to move forward with the Approach 2. Some feedback would be 
> great.
>

-- 
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/9ce02adc-ab52-44af-8274-dabc04208a10n%40googlegroups.com.

Re: HELP needed in a Reactjs Django project

[Dinesh Subramaniyam]

I have done like this where there is input in front end and data is passed
to django admin panel you have to make first crossorigin in django and then
make api structure in django and then pass it in reactjs call api from
axios I have code of it I will send you after some time understand it
simple code you will resolve your problem

On Fri, Oct 13, 2023, 19:44 Plamedi klj  wrote:

> Bien
>
> Le ven. 13 oct. 2023 à 14:14, Tejas Vaij  a
> écrit :
>
>> I am trying to upload a blob from a service-worker in react-js to a
>> django server but for some reason it is not getting uploaded. I have tried
>> a lot of things but nothing seems to be working. Can anyone please help me
>> know what is going wrong with my code.
>>
>> Here is the stackoverflow link where I have mentioned about the problem
>> in detail
>>
>> https://stackoverflow.com/questions/77280149/not-able-to-upload-file-to-django-server-from-service-worker-in-react-js
>>
>> --
>> 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/a1255819-e1c5-40fe-925d-406c9683fa53n%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/CABZ%3D34h5knp_Nz0P3kO9p%3D9%3DW30wxNrZHe9SokSwu0iFOW40Ew%40mail.gmail.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/CAFmGLqmw2_30qvZ%2BELtyzhcQ-%3DhJ0Sb%2BQrgeM6Js%2BvFJu8XKTA%40mail.gmail.com.

Re: HELP needed in a Reactjs Django project

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

Hi!

I think you've found the wrong mailing list for this post. This mailing list is 
for discussing the development of Django itself, not for support using Django. 
This means the discussions of bugs and features in Django itself, rather than 
in your code using it. People on this list are unlikely to answer your support 
query with their limited time and energy.

For support, please follow the "Getting Help" page: 
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find 
people who are willing to support you, and to ask your question in a way that 
makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Thu, Oct 12, 2023, at 8:03 AM, Plamedi klj wrote:
> Bien
> 
> Le ven. 13 oct. 2023 à 14:14, Tejas Vaij  a écrit :
>> I am trying to upload a blob from a service-worker in react-js to a django 
>> server but for some reason it is not getting uploaded. I have tried a lot of 
>> things but nothing seems to be working. Can anyone please help me know what 
>> is going wrong with my code.
>> 
>> Here is the stackoverflow link where I have mentioned about the problem in 
>> detail
>> https://stackoverflow.com/questions/77280149/not-able-to-upload-file-to-django-server-from-service-worker-in-react-js
>> 
>> 
>> -- 
>> 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/a1255819-e1c5-40fe-925d-406c9683fa53n%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/CABZ%3D34h5knp_Nz0P3kO9p%3D9%3DW30wxNrZHe9SokSwu0iFOW40Ew%40mail.gmail.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/a8894a08-62ab-4820-8297-4bdc1d72963c%40app.fastmail.com.

Re: HELP needed in a Reactjs Django project

[Plamedi klj]

Bien

Le ven. 13 oct. 2023 à 14:14, Tejas Vaij  a écrit :

> I am trying to upload a blob from a service-worker in react-js to a django
> server but for some reason it is not getting uploaded. I have tried a lot
> of things but nothing seems to be working. Can anyone please help me know
> what is going wrong with my code.
>
> Here is the stackoverflow link where I have mentioned about the problem in
> detail
>
> https://stackoverflow.com/questions/77280149/not-able-to-upload-file-to-django-server-from-service-worker-in-react-js
>
> --
> 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/a1255819-e1c5-40fe-925d-406c9683fa53n%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/CABZ%3D34h5knp_Nz0P3kO9p%3D9%3DW30wxNrZHe9SokSwu0iFOW40Ew%40mail.gmail.com.

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

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

I’ve created a PR with a suggested improvement: 
https://github.com/django/django/pull/17359 .

On Thu, Oct 12, 2023, at 5:09 AM, Mariusz Felisiak wrote:
> > Thoughts on this?
> 
> Documentation improvements are always welcome, you can send your proposition 
> via GitHub PR.
> 
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5088719c-22e9-40b5-9585-a1a2bfd39ec1n%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/8dedd63f-927c-4839-a1b8-6573c04a11df%40app.fastmail.com.

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

[Mariusz Felisiak]

> Thoughts on this?

Documentation improvements are always welcome, you can send your 
proposition via GitHub PR.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5088719c-22e9-40b5-9585-a1a2bfd39ec1n%40googlegroups.com.

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

[Michael]

Pardon, @Mariusz, I didn't mean to specify "non-text fields" - I had 
re-worded that sentence before posting.

On Wednesday, October 11, 2023 at 2:29:58 AM UTC-4 Mariusz Felisiak wrote:

> My immediate thought is that any indexes on non-text fields, created with 
> these versions, will be useless in ORM-based queries. If that's the case, 
> this seems like a much bigger deal than the footnote would imply.
>
>
> I'm puzzled. Why you assumed that all non-string based fields are 
> affected? Release note explicitly specifies what kind of indexes are 
> affected:
>
> Indexes *"on string based fields (CharField, EmailField, TextField, 
> CICharField, CIEmailField, and CITextField) used with the __isnull lookup 
> on PostgreSQL".*
>
> Do you it's worth mentioning again after *"You may need to recreate 
> indexes.."?* For example
>
> *"You may need to recreate indexes on string based fields (CharField, 
> EmailField, TextField, CICharField, CIEmailField, and CITextField) used 
> with the __isnull lookup propagated to the PostgreSQL database with Django 
> 4.2 - 4.2.5, as they contain unnecessary ::text casting that is avoided as 
> of this release."*
>
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/726c4a23-6795-4e8e-aa4e-238b9ab2dba1n%40googlegroups.com.

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

[Mariusz Felisiak]

My immediate thought is that any indexes on non-text fields, created with 
these versions, will be useless in ORM-based queries. If that's the case, 
this seems like a much bigger deal than the footnote would imply.


I'm puzzled. Why you assumed that all non-string based fields are affected? 
Release note explicitly specifies what kind of indexes are affected:

Indexes *"on string based fields (CharField, EmailField, TextField, 
CICharField, CIEmailField, and CITextField) used with the __isnull lookup 
on PostgreSQL".*

Do you it's worth mentioning again after *"You may need to recreate 
indexes.."?* For example

*"You may need to recreate indexes on string based fields (CharField, 
EmailField, TextField, CICharField, CIEmailField, and CITextField) used 
with the __isnull lookup propagated to the PostgreSQL database with Django 
4.2 - 4.2.5, as they contain unnecessary ::text casting that is avoided as 
of this release."*

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a6a82877-eb21-45a7-bc1c-6fe055aaa650n%40googlegroups.com.

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

[אורי]

Hi,

I also think a more specific documentation as to how to fix this issue is
required.

I usually upgrade Django about 6 months after the initial major release,
which is this month. But because of this issue I decided to wait 2 more
months.

Thanks,
Uri.
אורי
u...@speedy.net


On Wed, Oct 11, 2023 at 12:32 AM Michael  wrote:

> The release notes on https://docs.djangoproject.com/en/dev/releases/4.2.6/
> contain:
>
> > You may need to recreate indexes propagated to the database with Django
> 4.2 - 4.2.5 as they contain unnecessary ::text casting that is avoided as
> of this release.
>
> This doesn't give much context or give any guidance on how best to handle
> this, whether Django could help, etc.
>
> It also doesn't clarify why this is a "may need to" situation. Were Django
> versions 4.2-4.2.5 randomly doing this from time to time, or is this
> actually "you definitely do need to" situation; or is only relevant in
> specific scenarios?
>
> My immediate thought is that any indexes on non-text fields, created with
> these versions, will be useless in ORM-based queries. If that's the case,
> this seems like a much bigger deal than the footnote would imply.
>
> Thoughts on this?
>
> --
> 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/e686415b-0c4b-4643-8d0f-707aa859992bn%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/CABD5YeGKoznt-svAZkc8kCXnJLQXT8qdUh5KxNpKrVMChDozwA%40mail.gmail.com.

Re: Link to alternative Python resource

[Amogh]

It seems plausible to me. I'll try to look into other places where it has 
been repeated and try to make a PR.

On Monday, 9 October 2023 at 20:58:15 UTC+5:30 Adam Johnson wrote:

> I think it would be better to remove the link from the contribution guide, 
> since it’s quite advanced. The recommendation for the tutorial and “you 
> should have a good understanding of Python itself” seem sufficient to me.
>
> I noticed we have other “Dive Into Python” links throughout the docs. 
> These could be updated to the official Python docs.
>
> On Thu, Oct 5, 2023, at 2:09 AM, Amogh wrote:
>
> Hey there, I was going through Writing your first patch for Django 
> , there is a 
> link to Dive Into Python 
> , and apart from the 
> table of contents, it seems that the resource is pretty old. I was thinking 
> of updating with some new resources that are freely available online. My 
> first preference would be the official documentation of Python.
>
> It's not technical, but something that I noticed along the way.
>
> What do you folks think? Do you have any recommendations?
>  
>
>
>
> -- 
> 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/3c274347-f5e3-4bcc-973c-ddb141dec649n%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/9ce44323-c6c0-419e-9597-ba0e426023e4n%40googlegroups.com.

Re: Link to alternative Python resource

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

I think it would be better to remove the link from the contribution guide, 
since it’s quite advanced. The recommendation for the tutorial and “you should 
have a good understanding of Python itself” seem sufficient to me.

I noticed we have other “Dive Into Python” links throughout the docs. These 
could be updated to the official Python docs.

On Thu, Oct 5, 2023, at 2:09 AM, Amogh wrote:
> Hey there, I was going through Writing your first patch for Django 
> , there is a link 
> to Dive Into Python , 
> and apart from the table of contents, it seems that the resource is pretty 
> old. I was thinking of updating with some new resources that are freely 
> available online. My first preference would be the official documentation of 
> Python.
> 
> It's not technical, but something that I noticed along the way.
> 
> What do you folks think? Do you have any recommendations?
>  
> 
> 
> 
> 
> -- 
> 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/3c274347-f5e3-4bcc-973c-ddb141dec649n%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/e37db0f8-d0c7-4c8d-9fe5-58b79b056ee1%40app.fastmail.com.

Re: Update returning

[Tom Carrick]

I think it's okay to return something else based on a parameter. This is
already done for e.g. values_list(flat=True) and values_list(named=True).

While the bool addresses the obvious footgun I think it also loses a lot of
flexibility. If you have a field modified by a pre-update trigger or a
generated field that uses a field you updated, you wouldn't be able to see
these without another query, as I understand it.

On Sat, 7 Oct 2023 at 19:20, aivars.kalv...@gmail.com <
aivars.kalv...@gmail.com> wrote:

> Hi!
>
> I considered making `returning: bool` a flag that we are returning data.
> That would make it  `Foo.objects.update(x=1, y=2, returning=True)` and
> avoid some footguns. Or even a new function (`update_returning`?) because I
> have mixed feelings about different return types based on parameters.
>
> Returning fields other than ones updated is a valid case IMO: we can
> update some records and return the PKs of updated records for logging
> instead of having just the number of rows updated. Something
> like`.values_list('pk', flat=True)` is useful then.
>
>
>
>
>
> On Sat, Oct 7, 2023 at 6:46 PM Tom Carrick  wrote:
>
>> Hi Aivars,
>>
>> Since we spoke yesterday I've been thinking about this...
>>
>> I don't really see the value in returning a QuerySet. There are only a
>> limited number of options that make sense at this point, and even those are
>> tough to justify. Like what would happen if you do `Foo.objects.update(x=1,
>> returning=["x"]).values("y")`?
>>
>> I do see value in returning the model instances, though I feel there is a
>> potential footgun here where you can update a field, but not return it, so
>> you'd get the old value in the instance. Something like:
>>
>> `Foo.objects.update(x=1, y=2, returning=["x"])`
>>
>> Now you have updated y, but the model instance that gets returned still
>> has the old value. Maybe this is fine with a warning in the docs.
>>
>> I think regardless of what we do here, we should stick with the proposed
>> and roughly agreed upon API of having an extra argument to `update()`
>> rather than creating a new QuerySet method.
>>
>> Cheers,
>> Tom
>>
>>
>> On Tue, 3 Oct 2023 at 23:38, Plamedi klj  wrote:
>>
>>> Bien
>>>
>>> Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns 
>>> a écrit :
>>>
 Hi!

 I want to implement these changes and I have a PR in the ticket
 https://code.djangoproject.com/ticket/32406
 At the moment I have a new `update_returning` method but I can easily
 replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you
 decide to add functionality to the existing method instead. I did a search
 on github and found only a single project with `returning` as model field.
 However the returned value in my implementation is a `QuerySet` and I
 can do `.get()`, `.only()`, `.defer()` and `.values()` or `.values_list()`
 on that. Mainly because my use case is updating and refreshing the model in
 a single database operation. The ticket has more examples. What do you
 think, do you see any issues with this approach?

 trešdiena, 2021. gada 12. maijs 15:18:50 UTC+3 Tom Carrick rakstīja:

> Apologies, I had totally forgotten about this, but I'm still
> interested in working on it, but still not sure about a few things.
>
> I've been thinking about the return value a bit. I can foresee cases
> where you wouldn't want the id returned.  You might want the user to 
> update
> something by slug, username, or some other identifier without revealing 
> the
> IDs. Of course the user could reformat the return value however they like,
> but I don't see a reason to ask for something that isn't necessary.
>
> So I think a list of some kind of object (namedtuple or dict probably)
> makes the most sense to me. As for also adding the count, I am not sure.
> The return value would then be e.g. (1, []). I'm guessing this count
> would remain as the number of matched rows, rather than the updated ones -
> I am not sure if returning only gives back rows that were modified or not,
> the Postgres docs are at least unclear on this. If they're always going to
> be the same, I'm not sure there is much reason for returning the count 
> when
> len(return_value) will do.
>
> I'm also not really sure on the data structure though. Namedtuples
> make the most sense to me but a dict might be useful for those wanting to
> shove this directly into JsonResponse, without needing _asdict(), for
> example.
>
> Cheers,
> Tom
>
> On Wed, 27 Jan 2021 at 10:45, Florian Apolloner 
> wrote:
>
>> Hi Simon,
>>
>> On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
>>
>>> I think that's the best option here if we want to elegantly add
>>> support for this feature while maintaining backward compability. 
>>> Something
>>> along the lines of ...
>>>

Re: Update returning

[aivars.kalv...@gmail.com]

Hi!

I considered making `returning: bool` a flag that we are returning data.
That would make it  `Foo.objects.update(x=1, y=2, returning=True)` and
avoid some footguns. Or even a new function (`update_returning`?) because I
have mixed feelings about different return types based on parameters.

Returning fields other than ones updated is a valid case IMO: we can update
some records and return the PKs of updated records for logging instead of
having just the number of rows updated. Something like`.values_list('pk',
flat=True)` is useful then.





On Sat, Oct 7, 2023 at 6:46 PM Tom Carrick  wrote:

> Hi Aivars,
>
> Since we spoke yesterday I've been thinking about this...
>
> I don't really see the value in returning a QuerySet. There are only a
> limited number of options that make sense at this point, and even those are
> tough to justify. Like what would happen if you do `Foo.objects.update(x=1,
> returning=["x"]).values("y")`?
>
> I do see value in returning the model instances, though I feel there is a
> potential footgun here where you can update a field, but not return it, so
> you'd get the old value in the instance. Something like:
>
> `Foo.objects.update(x=1, y=2, returning=["x"])`
>
> Now you have updated y, but the model instance that gets returned still
> has the old value. Maybe this is fine with a warning in the docs.
>
> I think regardless of what we do here, we should stick with the proposed
> and roughly agreed upon API of having an extra argument to `update()`
> rather than creating a new QuerySet method.
>
> Cheers,
> Tom
>
>
> On Tue, 3 Oct 2023 at 23:38, Plamedi klj  wrote:
>
>> Bien
>>
>> Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns 
>> a écrit :
>>
>>> Hi!
>>>
>>> I want to implement these changes and I have a PR in the ticket
>>> https://code.djangoproject.com/ticket/32406
>>> At the moment I have a new `update_returning` method but I can easily
>>> replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you
>>> decide to add functionality to the existing method instead. I did a search
>>> on github and found only a single project with `returning` as model field.
>>> However the returned value in my implementation is a `QuerySet` and I
>>> can do `.get()`, `.only()`, `.defer()` and `.values()` or `.values_list()`
>>> on that. Mainly because my use case is updating and refreshing the model in
>>> a single database operation. The ticket has more examples. What do you
>>> think, do you see any issues with this approach?
>>>
>>> trešdiena, 2021. gada 12. maijs 15:18:50 UTC+3 Tom Carrick rakstīja:
>>>
 Apologies, I had totally forgotten about this, but I'm still interested
 in working on it, but still not sure about a few things.

 I've been thinking about the return value a bit. I can foresee cases
 where you wouldn't want the id returned.  You might want the user to update
 something by slug, username, or some other identifier without revealing the
 IDs. Of course the user could reformat the return value however they like,
 but I don't see a reason to ask for something that isn't necessary.

 So I think a list of some kind of object (namedtuple or dict probably)
 makes the most sense to me. As for also adding the count, I am not sure.
 The return value would then be e.g. (1, []). I'm guessing this count
 would remain as the number of matched rows, rather than the updated ones -
 I am not sure if returning only gives back rows that were modified or not,
 the Postgres docs are at least unclear on this. If they're always going to
 be the same, I'm not sure there is much reason for returning the count when
 len(return_value) will do.

 I'm also not really sure on the data structure though. Namedtuples make
 the most sense to me but a dict might be useful for those wanting to shove
 this directly into JsonResponse, without needing _asdict(), for example.

 Cheers,
 Tom

 On Wed, 27 Jan 2021 at 10:45, Florian Apolloner 
 wrote:

> Hi Simon,
>
> On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
>
>> I think that's the best option here if we want to elegantly add
>> support for this feature while maintaining backward compability. 
>> Something
>> along the lines of ...
>>
>
> That is certainly an interesting approach. It kinda breaks the "there
> should be one way of doing things" rule, but…
>
> The usage of `returning` bring another set of questions though. Since
>> UPDATE are not ordered RETURNING data has little value without the 
>> primary
>> key associated with the updated rows. Maybe the return value of
>> `returning=[f1, ..., fn]` should be a dict mapping the primary key to 
>> list
>> of returning values.
>>
>
> I am not sure I like that. For things where you update just one row
> and want to know the new values the primary key doesn't make much 

Re: Update returning

[Tom Carrick]

Hi Aivars,

Since we spoke yesterday I've been thinking about this...

I don't really see the value in returning a QuerySet. There are only a
limited number of options that make sense at this point, and even those are
tough to justify. Like what would happen if you do `Foo.objects.update(x=1,
returning=["x"]).values("y")`?

I do see value in returning the model instances, though I feel there is a
potential footgun here where you can update a field, but not return it, so
you'd get the old value in the instance. Something like:

`Foo.objects.update(x=1, y=2, returning=["x"])`

Now you have updated y, but the model instance that gets returned still has
the old value. Maybe this is fine with a warning in the docs.

I think regardless of what we do here, we should stick with the proposed
and roughly agreed upon API of having an extra argument to `update()`
rather than creating a new QuerySet method.

Cheers,
Tom


On Tue, 3 Oct 2023 at 23:38, Plamedi klj  wrote:

> Bien
>
> Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns 
> a écrit :
>
>> Hi!
>>
>> I want to implement these changes and I have a PR in the ticket
>> https://code.djangoproject.com/ticket/32406
>> At the moment I have a new `update_returning` method but I can easily
>> replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you
>> decide to add functionality to the existing method instead. I did a search
>> on github and found only a single project with `returning` as model field.
>> However the returned value in my implementation is a `QuerySet` and I can
>> do `.get()`, `.only()`, `.defer()` and `.values()` or `.values_list()` on
>> that. Mainly because my use case is updating and refreshing the model in a
>> single database operation. The ticket has more examples. What do you think,
>> do you see any issues with this approach?
>>
>> trešdiena, 2021. gada 12. maijs 15:18:50 UTC+3 Tom Carrick rakstīja:
>>
>>> Apologies, I had totally forgotten about this, but I'm still interested
>>> in working on it, but still not sure about a few things.
>>>
>>> I've been thinking about the return value a bit. I can foresee cases
>>> where you wouldn't want the id returned.  You might want the user to update
>>> something by slug, username, or some other identifier without revealing the
>>> IDs. Of course the user could reformat the return value however they like,
>>> but I don't see a reason to ask for something that isn't necessary.
>>>
>>> So I think a list of some kind of object (namedtuple or dict probably)
>>> makes the most sense to me. As for also adding the count, I am not sure.
>>> The return value would then be e.g. (1, []). I'm guessing this count
>>> would remain as the number of matched rows, rather than the updated ones -
>>> I am not sure if returning only gives back rows that were modified or not,
>>> the Postgres docs are at least unclear on this. If they're always going to
>>> be the same, I'm not sure there is much reason for returning the count when
>>> len(return_value) will do.
>>>
>>> I'm also not really sure on the data structure though. Namedtuples make
>>> the most sense to me but a dict might be useful for those wanting to shove
>>> this directly into JsonResponse, without needing _asdict(), for example.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Wed, 27 Jan 2021 at 10:45, Florian Apolloner 
>>> wrote:
>>>
 Hi Simon,

 On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:

> I think that's the best option here if we want to elegantly add
> support for this feature while maintaining backward compability. Something
> along the lines of ...
>

 That is certainly an interesting approach. It kinda breaks the "there
 should be one way of doing things" rule, but…

 The usage of `returning` bring another set of questions though. Since
> UPDATE are not ordered RETURNING data has little value without the primary
> key associated with the updated rows. Maybe the return value of
> `returning=[f1, ..., fn]` should be a dict mapping the primary key to list
> of returning values.
>

 I am not sure I like that. For things where you update just one row and
 want to know the new values the primary key doesn't make much sense.
 Granted for multiple rows it would maybe easier to have it automatically
 keyed by the pk, but returning something always (the pk) without having an
 option to disable  it seems kinda wrong to me. Not sure what the best
 option would be.

 Cheers,
 Florian

 --

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

Re: Fellow Reports - September 2023

[Mariusz Felisiak]

Week ending October 1, 2023

*Triaged:*
https://code.djangoproject.com/ticket/34866 - Cannot inspect migrations 
that replace squashed migrations with sqlmigrate (needsinfo)
https://code.djangoproject.com/ticket/34871 - Validation of 
UniqueConstraint with Case() crashes. (accepted)
https://code.djangoproject.com/ticket/34841 - Reverse migrations model 
state rendering slow with moderate to large migrations (accepted)
https://code.djangoproject.com/ticket/34870 - Memory leak when using 
psycopg-c with django hstore (invalid)
https://code.djangoproject.com/ticket/34873 - Add support for 
GENERIC_PLAN option to QuerySet.explain() on PostgreSQL 16+. (created)
https://code.djangoproject.com/ticket/34874 - Add table_exists() to 
optimize checks for django_migrations table. (wontfix)
https://code.djangoproject.com/ticket/34876 - Allow password reset 
token generator to configure timeouts (duplicate)
https://code.djangoproject.com/ticket/34875 - Use RFC 9106 
recommendations in Argon2PasswordHasher (wontfix)
https://code.djangoproject.com/ticket/34878 - Autoreload crashes with 
FORM_RENDERER="django.forms.renderers.TemplatesSetting". (accepted)
https://code.djangoproject.com/ticket/34879 - "Data truncated for 
column .." for migration changing auto-id-field (worksforme)
https://code.djangoproject.com/ticket/34881 - migrate crashes when 
renaming model referenced twice by ManyToManyField.through model on SQLite. 
(accepted)
https://code.djangoproject.com/ticket/34882 - options=0 is not 
respected when calling AsGeoJSON() (accepted)
https://code.djangoproject.com/ticket/34883 - Allow template tags to 
set extra data on templates. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/17300 - Fixed #34849 -- Avoided 
raising RuntimeWarning about import-time queries when apps are 
reinitialized with test tools.
https://github.com/django/django/pull/17242 - Fixed #34825 -- Avoided 
setting unused connections when initializing parallel workers.
https://github.com/django/django/pull/17314 - Fixed #34877 -- Fixed 
migrations crash when adding GeneratedField with output_field with params.
https://github.com/django/django/pull/17318 - Fixed #34878 -- Fixed 
autoreloader crash when FORM_RENDERER is set to TemplatesSetting.
https://github.com/django/django/pull/17321 - Refs #34657 -- Made 
assertInHTML() use unparsed needle in error messages.

*Authored:*
https://github.com/django/django/pull/17310 - Fixed #34873 -- Added 
QuerySet.explain() support for GENERIC_PLAN option on PostgreSQL 16+.
https://github.com/django/django/pull/17311 - Added warning about 
flatpages and untrusted users.
https://github.com/django/django/pull/17312 - [4.2.x] Refs #34320 -- 
Skipped SchemaTests.test_rename_field_with_check_to_truncated_name on 
MariaBD 10.5.2+.
https://github.com/django/django/pull/17315 - Refs #15667 -- Added 
resetting default renderer when FORM_RENDERER is changed.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/59dd3865-9b01-4a4a-be85-80bae8494ae7n%40googlegroups.com.

Re: Update returning

[Plamedi klj]

Bien

Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns  a
écrit :

> Hi!
>
> I want to implement these changes and I have a PR in the ticket
> https://code.djangoproject.com/ticket/32406
> At the moment I have a new `update_returning` method but I can easily
> replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you
> decide to add functionality to the existing method instead. I did a search
> on github and found only a single project with `returning` as model field.
> However the returned value in my implementation is a `QuerySet` and I can
> do `.get()`, `.only()`, `.defer()` and `.values()` or `.values_list()` on
> that. Mainly because my use case is updating and refreshing the model in a
> single database operation. The ticket has more examples. What do you think,
> do you see any issues with this approach?
>
> trešdiena, 2021. gada 12. maijs 15:18:50 UTC+3 Tom Carrick rakstīja:
>
>> Apologies, I had totally forgotten about this, but I'm still interested
>> in working on it, but still not sure about a few things.
>>
>> I've been thinking about the return value a bit. I can foresee cases
>> where you wouldn't want the id returned.  You might want the user to update
>> something by slug, username, or some other identifier without revealing the
>> IDs. Of course the user could reformat the return value however they like,
>> but I don't see a reason to ask for something that isn't necessary.
>>
>> So I think a list of some kind of object (namedtuple or dict probably)
>> makes the most sense to me. As for also adding the count, I am not sure.
>> The return value would then be e.g. (1, []). I'm guessing this count
>> would remain as the number of matched rows, rather than the updated ones -
>> I am not sure if returning only gives back rows that were modified or not,
>> the Postgres docs are at least unclear on this. If they're always going to
>> be the same, I'm not sure there is much reason for returning the count when
>> len(return_value) will do.
>>
>> I'm also not really sure on the data structure though. Namedtuples make
>> the most sense to me but a dict might be useful for those wanting to shove
>> this directly into JsonResponse, without needing _asdict(), for example.
>>
>> Cheers,
>> Tom
>>
>> On Wed, 27 Jan 2021 at 10:45, Florian Apolloner 
>> wrote:
>>
>>> Hi Simon,
>>>
>>> On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
>>>
 I think that's the best option here if we want to elegantly add support
 for this feature while maintaining backward compability. Something along
 the lines of ...

>>>
>>> That is certainly an interesting approach. It kinda breaks the "there
>>> should be one way of doing things" rule, but…
>>>
>>> The usage of `returning` bring another set of questions though. Since
 UPDATE are not ordered RETURNING data has little value without the primary
 key associated with the updated rows. Maybe the return value of
 `returning=[f1, ..., fn]` should be a dict mapping the primary key to list
 of returning values.

>>>
>>> I am not sure I like that. For things where you update just one row and
>>> want to know the new values the primary key doesn't make much sense.
>>> Granted for multiple rows it would maybe easier to have it automatically
>>> keyed by the pk, but returning something always (the pk) without having an
>>> option to disable  it seems kinda wrong to me. Not sure what the best
>>> option would be.
>>>
>>> Cheers,
>>> Florian
>>>
>>> --
>>>
>> 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/4eea605a-57d7-4ce3-b233-3eb88c91e110n%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/ee284d47-6181-426d-98fd-3a0e50e0d9abn%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 

Re: Looking for a code that separates fields while applying migrations

[Akash Sen]

This one worked :   SQL: 
https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/models/fields/__init__.py#L142
 .
Thank you Adam.

On Monday, October 2, 2023 at 3:44:34 PM UTC+5:30 Adam Johnson wrote:

> See alte_field in the schema editor: 
> https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/backends/base/schema.py#L811
>
> It steps through what has changed in the field and generates SQL for the 
> database relevant changes, queueing up statements with self.execute. Any 
> non-SQL changes are basically ignored.
>
> Field.non_db_attrs tracks the field attributes rhat don’t affect SQL: 
> https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/models/fields/__init__.py#L142
>  . 
> Note they may be modified by field subclasses, such as inDjango-MySQL’s 
> EnumField.
>
> On Sat, Sep 30, 2023, at 3:57 PM, Akash Sen wrote:
>
> Hello everyone,
> There are certain attributes in a field, after changing these the 
> migration generated willbe applied to database, (for example take 
> foreignkey) like null=True or db_default=1. As they have something to do 
> with the database column.
> There are some other attributes after changing these the migration 
> generated will not be applied to database, like on_delete. As currently 
> they have nothing to do with the database column.
> In search of the code that takes care of that. Some help would be great!
>
>
> -- 
> 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/12539052-6e21-491a-b79e-e63edf451165n%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/c0b8d3cc-cef3-411a-a975-21db8aa70acfn%40googlegroups.com.

Re: Looking for a code that separates fields while applying migrations

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

See alte_field in the schema editor: 
https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/backends/base/schema.py#L811

It steps through what has changed in the field and generates SQL for the 
database relevant changes, queueing up statements with self.execute. Any 
non-SQL changes are basically ignored.

Field.non_db_attrs tracks the field attributes rhat don’t affect SQL: 
https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/models/fields/__init__.py#L142
 . Note they may be modified by field subclasses, such as inDjango-MySQL’s 
EnumField.

On Sat, Sep 30, 2023, at 3:57 PM, Akash Sen wrote:
> Hello everyone,
> There are certain attributes in a field, after changing these the migration 
> generated willbe applied to database, (for example take foreignkey) like 
> null=True or db_default=1. As they have something to do with the database 
> column.
> There are some other attributes after changing these the migration generated 
> will not be applied to database, like on_delete. As currently they have 
> nothing to do with the database column.
> In search of the code that takes care of that. Some help would be great!
> 
> 
> -- 
> 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/12539052-6e21-491a-b79e-e63edf451165n%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/e715548d-fbac-4813-b84f-dfec962d62a4%40app.fastmail.com.

Re: (Circa end of 2021) Localization issues with input type=date?

[natali...@gmail.com]

On Thursday, November 10, 2022 at 5:40:45 AM UTC-3 Jacob Rief wrote:

How about ditching the JS based datepicker altogether and replace it 
against the built-in datepicker offered by modern browsers? This would also 
help users of mobile devices because they already have good internal 
implementations to select a date. I agree that on desktop browsers the 
built-in datepicker does not really look nice, but IMO still works way 
better than the  widget, (ab-)used for date types as 
currently implemented in Django. 

A compromise for the Django Admin could be to detect the CSS query "@media 
(pointer:coarse)". If this matches, it's a mobile device and we can fall 
back on the internal date selector. Otherwise use a nice looking JS 
implementation.

There is a good article on CSS Tricks about date input types:
https://css-tricks.com/better-form-inputs-for-better-mobile-user-experiences/#aa-a-quick-detour-into-date-types

Btw., since PR#15806  is 
stale, may I reclaim it?


I have pinged the original author asking if they can continue, if they 
can't or do not reply in a few weeks, please do so!

-- 
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/162c8ff3-968a-4e88-b364-6018adcdbf2cn%40googlegroups.com.

Re: Update returning

[Aivars Kalvāns]

Hi!

I want to implement these changes and I have a PR in the 
ticket https://code.djangoproject.com/ticket/32406
At the moment I have a new `update_returning` method but I can easily 
replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you 
decide to add functionality to the existing method instead. I did a search 
on github and found only a single project with `returning` as model field.
However the returned value in my implementation is a `QuerySet` and I can 
do `.get()`, `.only()`, `.defer()` and `.values()` or `.values_list()` on 
that. Mainly because my use case is updating and refreshing the model in a 
single database operation. The ticket has more examples. What do you think, 
do you see any issues with this approach?

trešdiena, 2021. gada 12. maijs 15:18:50 UTC+3 Tom Carrick rakstīja:

> Apologies, I had totally forgotten about this, but I'm still interested in 
> working on it, but still not sure about a few things.
>
> I've been thinking about the return value a bit. I can foresee cases where 
> you wouldn't want the id returned.  You might want the user to update 
> something by slug, username, or some other identifier without revealing the 
> IDs. Of course the user could reformat the return value however they like, 
> but I don't see a reason to ask for something that isn't necessary.
>
> So I think a list of some kind of object (namedtuple or dict probably) 
> makes the most sense to me. As for also adding the count, I am not sure. 
> The return value would then be e.g. (1, []). I'm guessing this count 
> would remain as the number of matched rows, rather than the updated ones - 
> I am not sure if returning only gives back rows that were modified or not, 
> the Postgres docs are at least unclear on this. If they're always going to 
> be the same, I'm not sure there is much reason for returning the count when 
> len(return_value) will do.
>
> I'm also not really sure on the data structure though. Namedtuples make 
> the most sense to me but a dict might be useful for those wanting to shove 
> this directly into JsonResponse, without needing _asdict(), for example.
>
> Cheers,
> Tom
>
> On Wed, 27 Jan 2021 at 10:45, Florian Apolloner  
> wrote:
>
>> Hi Simon,
>>
>> On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
>>
>>> I think that's the best option here if we want to elegantly add support 
>>> for this feature while maintaining backward compability. Something along 
>>> the lines of ...
>>>
>>
>> That is certainly an interesting approach. It kinda breaks the "there 
>> should be one way of doing things" rule, but…
>>
>> The usage of `returning` bring another set of questions though. Since 
>>> UPDATE are not ordered RETURNING data has little value without the primary 
>>> key associated with the updated rows. Maybe the return value of 
>>> `returning=[f1, ..., fn]` should be a dict mapping the primary key to list 
>>> of returning values.
>>>
>>
>> I am not sure I like that. For things where you update just one row and 
>> want to know the new values the primary key doesn't make much sense. 
>> Granted for multiple rows it would maybe easier to have it automatically 
>> keyed by the pk, but returning something always (the pk) without having an 
>> option to disable  it seems kinda wrong to me. Not sure what the best 
>> option would be.
>>
>> Cheers,
>> Florian
>>
>> -- 
>>
> 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/4eea605a-57d7-4ce3-b233-3eb88c91e110n%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/ee284d47-6181-426d-98fd-3a0e50e0d9abn%40googlegroups.com.

Re: Django in Portuguese

[אורי]

Hi,

I created the following issue: https://code.djangoproject.com/ticket/34854

Thanks,
Uri.
אורי
u...@speedy.net


‪On Tue, Sep 19, 2023 at 9:57 PM ‫אורי‬‎  wrote:‬

> Django Developers,
>
> I need to translate my website (Django) to Portuguese (Europe/Portugal
> version). I translated the site and I was surprised to see that a specific
> error message was in English (from FileExtensionValidator). I checked and
> found out that there are many untranslated strings in language code pt,
> although they are translated in pt_BR. What's the difference and isn't it
> better to copy all the missing translations from pt_BR to pt, rather than
> display them in English to the visitors of sites such as mine? I mean they
> might understand English, but the site is meant to be in Portuguese. I
> think the minimum is to show them pt_BR translations if pt translations are
> missing.
>
> I checked other po files such as de, es, it and nl and there are no
> missing translations there.
>
> Thanks,
> Uri Rodberg, Speedy Net.
> אורי
> u...@speedy.net
>

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

Re: Proposal: Clarify individual members page

[Andrew Mshar]

 Small typo in my previous post. Clearly I meant I'll open the PR next 
year...

Better late than never, here is the PR with changes from my previous draft 
based on everyone's input: 
https://github.com/django/djangoproject.com/pull/1406

Thanks again for all the feedback.

On Friday, November 11, 2022 at 1:52:07 PM UTC-5 Andrew Mshar wrote:

> I like that idea, Tim. A few things came up, so I'll open this PR next 
> week.
>
> Thanks,
> Andrew
>
> On Friday, November 11, 2022 at 12:21:43 PM UTC-5 schill...@gmail.com 
> wrote:
>
>> Hi folks!
>>
>> Andrew (Mshar) how do you feel about reworking:
>>
>> > If you know someone who you think should be considered for Individual 
>> Membership or would like to nominate yourself, please fill out this form 
>> 
>> .
>>
>> To something that places more focus on self-nomination, with nominating 
>> others as the alternative such as:
>>
>> If you would like to apply for Individual Membership, please fill out 
>> this form. You can also nominate others if you know someone who should be 
>> considered.
>>
>> My reasoning:
>>
>>- The use of "apply" rather than "nominate yourself". People are used 
>>to applying for things for themselves. I imagine fewer nominate 
>> themselves 
>>for things making it less comfortable. I think using language that's more 
>>comfortable will encourage people.
>>- Moving the nomination of others to the end highlights that applying 
>>for yourself is not the exception flow. Again, this should help encourage 
>>people to apply.
>>
>>
>> Thanks for driving this!
>>
>> On Tue, Nov 8, 2022 at 10:24 PM Andrew Godwin  
>> wrote:
>>
>>> Just want to pop in and say these are great ideas - feel free to copy me 
>>> in on any PR if you want extra opinions!
>>>
>>> On Tuesday, November 8, 2022 at 8:26:28 AM UTC-7 Carlton Gibson wrote:
>>>
 Great, Thanks Andrew. No urgency 

 On Tue, 8 Nov 2022 at 16:16, Andrew Mshar  wrote:

> Will do, Carlton.
>
> Tim and Cory, thanks for the suggestions. I'll incorporate those in 
> the PR and post here when it's ready. Probably not today, but I should be 
> able to open it before the end of the week.
>
> Thanks,
> Andrew
>
> On Tuesday, November 8, 2022 at 10:10:51 AM UTC-5 carlton...@gmail.com 
> wrote:
>
>> Hey Andrew. 
>>
>> I had thought this was a Flatpage (stored in the database) but it's 
>> not. 
>> The source is here: 
>> https://github.com/django/djangoproject.com/blob/main/djangoproject/templates/members/individualmember_list.html
>> If you wanted to open a PR suggesting your changes, that would be 
>> amazing 朗
>>
>> Thanks. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Mon, 7 Nov 2022 at 19:51, Tim Allen  
>> wrote:
>>
>>> I'm of the opinion that if you care enough about Django to 
>>> investigate becoming a member of the DSF, that's enough of a 
>>> qualification 
>>> - it is just challenging to formalize that into proper text for the 
>>> website. Maybe two changes to encourage people to join:
>>>
>>>- We could tweak *"Running Django-related events or user 
>>>groups"  *to *"Attending or organizing Django-related events or 
>>>user groups"*.
>>>- Add a sentence to the end of the first stanza: "The following 
>>>are Individual Members of the Django Software Foundation. The DSF 
>>> appoints 
>>>individual Members in recognition of their service to the Django 
>>> community. 
>>>If you would like to join the DSF, we welcome you. Please feel free 
>>> to 
>>>self-nominate for membership."
>>>
>>> Regards,
>>>
>>> Tim
>>>
>>> On Monday, November 7, 2022 at 11:12:41 AM UTC-5 cory...@gmail.com 
>>> wrote:
>>>
 Hey Andrew,

 Thanks for drafting this language and I think it looks great. As 
 someone who only recently applied after hearing it discussed on an 
 episode 
 of Django Chat[1], I'm all for the goals of making it more encouraging 
 and 
 accessible and think this is a great step in that direction.

 Here are a few minor thoughts to specific bits:

 Service to the Django community takes many forms. Here are some 
> examples (non-exhaustive) of categories of work performed by members:
>

 "performed by members" is a little ambiguous as to whether it means 
 "this is how we evaluate applicants" vs "this is what you'll do if 
 part of 
 the DSF". Since I think the intention is the former it might make 
 sense to 
 change to something like:

 *Service to the Django community takes many forms. Here are some 
 

RE: Allow applications to register links in the admin interface

[Matthew Pava]

I reviewed some of the history of this ticket. I tend to agree with the 
criticisms of adding something akin to an AdminURL to the Django admin.

However, the idea of custom views to apps in the admin is an idea that I find 
appealing. The history of this ticket features a comment from Tim Graham 
pointing us back to this ticket:
https://code.djangoproject.com/ticket/18665?cversion=1_hist=3#comment:3
Allowing registering custom admin views with the admin’s index

It was opened 11 years ago and last modified 6 years ago. This points us to an 
external package.
https://github.com/koleror/django-admin-views

It looks like it already has URLs implemented in the Django admin interface, so 
it appears that the volunteer is performing duplicate work. The last update for 
that project was last year.

Our fellows should probably review both tickets to determine if they should be 
closed.
It does appear that Julien Phalip and Jacob Kaplan-Moss both wanted the 
features of Django-admin-views inside the admin app. That might be a 
conversation worth having.

From: django-developers@googlegroups.com  
On Behalf Of Shlomo
Sent: Wednesday, September 6, 2023 9:34 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Allow applications to register links in the admin interface

You have some great points that I definitely overlooked in the initial 
implementation. I don't think that overloading the template is a great solution 
since there are still some features that registered links will add that cannot 
be done with a simple template override.

  *It is easier to selectively show links to users based on the request or 
a custom permission in a method rather than in the template.
  *   Currently each app would have to override the navbar userlinks section 
completely and add their relevant links which would not work if another third 
party app also overrides the same section. Unless {{ block.super }} is used. {{ 
block.super }} is not a great option since it would limit links to be added to 
only the beginning of the block (before VIEW SITE) or the end (after the color 
theme toggle). It is also close to impossible to set the ordering of links when 
using the {{ block.super }} approach.
  *   No Django apps will add a quick links section to the admin and expect 
other apps to use that apps Quick Links section. If the Quick Links section is 
implemented many different apps can utilize this central location to put links. 
(a setting can be added to disable this)
  *   If the app is not sure if the user wants the admin to have the link the 
app can have the link class available and let the user register it.
The implementation can be changed to use a class-based approach. This will work 
similar to how the ModelAdmin class works. The target attribute and onClick can 
be set in the new AdminLink class. For users who need even more control it can 
have a method .to_html() with can be overridden to display the final html link 
element. To decide if a link should be shown to a specific user there can be 
another method called .will_display that will except a request object and will 
return True or False if that user can see the link or not.
This can even use the Django permissions framework by default to determine if 
the user should see the link or not. Similar to how the PermissionRequiredMixin 
works.
You will still be able to override the template if needed the same way as 
before.
I definitely hear that having modifiers using strings can be error prone and 
won't scale well but this can be changed to use ENUMS instead.

The user will be able to override any of these methods to customize how the 
links are displayed.

class RegisterDjango(admin.UrlAdmin):
menu_order = 5
on_click = None
permission_required = ["polls.view_choice", "polls.change_choice"]
url = "https://djangoproject.com<https://djangoproject.com/>"
name = "Django"
target = "_blank"
location = admin.Location.QUICK_LINKS

def get_location(self, request):
return self.location

def get_menu_order(self,request):
return self.menu_order

def get_on_click(self,request):
return self.on_click

def will_display(self,request):
if request.user.has_perms(self.permission_required):
return True
return False

def get_url(self,request):
return self.url

def get_target(self, request):
return self.target

def get_name(self, request):
return self.name

def to_html(self,request):
return f'{self.get_name(request)}'


admin.site.register_url(RegisterDjango)

Most apps will likely add additional links to the Quick Links section, so they 
won't need to be wrapped. This will also cause the navbar not to have so many 
links. If needed there can be a max links setting that can limit the number of 
additional links in the navbar.

As far as link ordering 

Re: Allow applications to register links in the admin interface

[Mariusz Felisiak]

I'm also -1.

Django Admin is not a universal tool for building an app 

 
and adding a new option is always controversial (we already have many of 
them). There is a way to achieve the same by providing custom templates.

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3a42d3a0-023d-4ee8-8e24-c2737d681bben%40googlegroups.com.