Re: queryset.iterator() and prefetch_related()

We've decided to open a ticket and MR for it: https://github.com/percipient/django-querysetsequence/issues/67 (that would happen this weekend) If there's any objection please let us know. Have a great day ‐‐‐ Original Message ‐‐‐ Le mardi, avril 28, 2020 6:39 PM, 1337 Shadow Hacker <1

Re: queryset.iterator() and prefetch_related()

FWIW there's ungoing work to allow iterator() to use prefetch_related() which would allow us to lift this restriction. See https://groups.google.com/forum/#!searchin/django-developers/iterator$20prefetch%7Csort:date/django-developers/ADgUd6jRvdw/_ZnETNlcAAAJ Cheers, Simon Le jeudi 11 juin 2020

Re: queryset.iterator() and prefetch_related()

Well that's good to know, thank you charettes ! Does that mean that the piece of code from forms that's using "private" API from QuerySet is going away in the next Django version ? In this case, we probably don't have to do anything on our end ? -- You received this message because you are sub

Re: queryset.iterator() and prefetch_related()

The code could possibly be removed if the PR gets merged in time for 3.2 yes. Le jeudi 11 juin 2020 09:44:32 UTC-4, 1337 Shadow Hacker a écrit : > > Well that's good to know, thank you charettes ! > > Does that mean that the piece of code from forms that's using "private" > API from QuerySet is

Re: queryset.iterator() and prefetch_related()

Awesome, thank you so much charettes. We're implementing the "private" attribute meanwhile so there's no rush. Have a great day -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this gro

Re: Management of static assets

Le samedi, mai 9, 2020 10:39 PM, Aymeric Augustin a écrit : > Perhaps Django could standardize a way to accumulate a list of CSS and JS > assets to include in a page, which could then be rendered in HTML, perhaps > after optimizations (provided by third party apps). The Cubic web framework ha

Defaulting to use BigAutoField in models

I’d like to re-propose switching Django to use BigAutoField’s rather than the current AutoField. This has been proposed[1] before (and a MR made[2]) but it was closed due to implementation issues and not much else has happened since then. As many of you are aware the max value a standard AutoFi

Re: Defaulting to use BigAutoField in models

For the record, there was a related discussion a few months ago: https://groups.google.com/d/msg/django-developers/VFXZpHnuEJc/bbefjX9yCQAJ > On 11 Jun 2020, at 12:28, Tom Forbes wrote: > > nsures it will be used meaningfully and not forgotten about until it’s too > late. > -- You received

Re: Defaulting to use BigAutoField in models

Big +1 on solving this from me. - The setting would take any dotted path to a class, or a single class name > for a build in field. This would potentially solve [3], and could be useful > to people who want to default to other fields like UUIDs (or a custom > BigAutoField) for whatever reason > I

./manage.py settings

Hi all, So, just on #django IRC channel there was a user trying to help another one, asking for some settings through ./manage.py shell etc ... A discussion that went kind of like "Print out your settings" "How would I print, I tried that, I'm in settings.py" "With ... print()" "but in the shel

Re: ./manage.py settings

I've always used `diffsettings` to print my settings for debugging purposes, and `diffsettings` combined with `| grep` to filter down to specific settings options. Was this option discussed in the IRC thread? https://docs.djangoproject.com/en/2.2/ref/django-admin/#diffsettings Best, Ion On Thu,