Re: ./manage.py settings

[Ion Scerbatiuc]

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, Jun 11, 2020 at 8:09 PM '1337 Shadow Hacker' via Django developers
(Contributions to Django itself)  wrote:

> 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
> shell, __file__ is not defined" and so on, and 20 minutes later the user
> couldn't print his settings and left.
>
> TBH I'm pretty fine because the users I support are on projects where I
> added djcli to the requirements, so I can always ask the to do the djcli
> setting command to print out a setting. It's very useful useful to me, I
> think Django should a command to dump runtime settings because that should
> make the life easier of Django users trying to support newbies in their own
> projects, where they don't have installed a custom command, it's pretty
> cheap to make and maintain and should save quite some frustration from both
> sides of the story.
>
> What do you think ?
>
>
> --
> 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/X2HkH0yasxu2XVxBuVkbTfdSHctL7y3pW9seQ8CHFcVOpmsiyN80JlDYH2g5F6IfPvEdN4zyG6vuxj2HEMJaXUSErMUM5IT70iLvkxsrc7U%3D%40protonmail.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/CAH26QPp5b-9cmy2Qt59VCfe8X-Q-a3m-S6GdQkAv-S3nf9ff0Q%40mail.gmail.com.

./manage.py settings

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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 shell, __file__ is not 
defined" and so on, and 20 minutes later the user couldn't print his settings 
and left.

TBH I'm pretty fine because the users I support are on projects where I added 
djcli to the requirements, so I can always ask the to do the djcli setting 
command to print out a setting. It's very useful useful to me, I think Django 
should a command to dump runtime settings because that should make the life 
easier of Django users trying to support newbies in their own projects, where 
they don't have installed a custom command, it's pretty cheap to make and 
maintain and should save quite some frustration from both sides of the story.
What do you think ?

-- 
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/X2HkH0yasxu2XVxBuVkbTfdSHctL7y3pW9seQ8CHFcVOpmsiyN80JlDYH2g5F6IfPvEdN4zyG6vuxj2HEMJaXUSErMUM5IT70iLvkxsrc7U%3D%40protonmail.com.

Re: Defaulting to use BigAutoField in models

[Adam Johnson]

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 think we should restrict the setting between normal and big auto fields
only. Allowing UUID's would be changing the type, with the potential for
havoc with code incompalities throughout django. It's also not possible to
migrate tables over to the new type.

What do you think the solution is for third-party apps? They ship their own
migrations and can't really be tied to project state.

As Django migrations are derived from the current model state so there’s no
> way I can think of to express “make this auto-generated field a
> BigAutoField only if this model is *new*”.
>

The autodetector knows if a model is new. It could be that during one
version Django outputs BigAutoField for fields added in CreateModel only.

On Thu, 11 Jun 2020 at 16:28, Tom Forbes  wrote:

> 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 AutoField can hold is
> 2,147,483,647 (2.1 billion) which sounds like more than you can ever need.
> But it’s often not, and you only find out at the worst possible time - out
> of the blue at night and during a period of rapid growth. The process for
> fixing this issue also becomes a lot harder as your data grows - when
> you’ve hit the limit you’re looking at a multi-hour `ALTER TABLE` on
> Postgres during which writes and reads are blocked, or a risky operation to
> create a new table with the correct primary key and copy old data over in
> batches. Basically if you’ve experienced this before you wouldn’t wish it
> on your worst enemy.
>
> I’m proposing that we add a `MODELS_PRIMARY_KEY` (name improvements
> welcome!) setting that _defaults_ to `BigAutoField`, with prominent
> docs/release notes saying that to preserve the existing behaviour this
> should be set to `AutoField`. I think this the only realistic way we can
> implement this for new projects in a way that ensures it will be used
> meaningfully and not forgotten about until it’s too late.
>
> Rails managed to do this migration somewhat painlessly due the big
> differences between Rails and Django models. As Django migrations are
> derived from the current model state so there’s no way I can think of to
> express “make this auto-generated field a BigAutoField only if this model
> is *new*”. The way I see it is that a global setting is very easy to
> toggle and there is little chance of missing the large numbers of
> migrations that would be generated during the Django update. Smaller
> applications could apply the migrations with little issue and larger
> applications would be able to opt-out (as well as be reminded that this is
> a problem they could face!).
>
> Some specifics:
> - 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
> - The setting would also be used for GenericForeignKeys, which right now
> are backed by a PositiveIntegerField and so suffer from the same AutoField
> limitations
>
> Any thoughts on this?
>
> Tom
>
> 1.
> https://groups.google.com/d/msg/django-developers/imBJwRrtJkk/P4g0Y87lAgAJ
>
> 2. https://github.com/django/django/pull/8924/
>
> 3. https://code.djangoproject.com/ticket/56
> 
>
>
>
> --
> 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/435EC704-3EF6-4EF4-BF85-175AE29C01F5%40tomforb.es
> 
> .
>


-- 
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/CAMyDDM1EbbffnydYkVZELcvX3d5y%3DprOCi-b0naYDsP0PRSOwA%40mail.gmail.com.

Re: Defaulting to use BigAutoField in models

[Caio Ariede]

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 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/4F05621B-F004-44B5-901E-29962D531804%40gmail.com.

Defaulting to use BigAutoField in models

[Tom Forbes]

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 AutoField can hold is 
2,147,483,647 (2.1 billion) which sounds like more than you can ever need. But 
it’s often not, and you only find out at the worst possible time - out of the 
blue at night and during a period of rapid growth. The process for fixing this 
issue also becomes a lot harder as your data grows - when you’ve hit the limit 
you’re looking at a multi-hour `ALTER TABLE` on Postgres during which writes 
and reads are blocked, or a risky operation to create a new table with the 
correct primary key and copy old data over in batches. Basically if you’ve 
experienced this before you wouldn’t wish it on your worst enemy.

I’m proposing that we add a `MODELS_PRIMARY_KEY` (name improvements welcome!) 
setting that _defaults_ to `BigAutoField`, with prominent docs/release notes 
saying that to preserve the existing behaviour this should be set to 
`AutoField`. I think this the only realistic way we can implement this for new 
projects in a way that ensures it will be used meaningfully and not forgotten 
about until it’s too late.

Rails managed to do this migration somewhat painlessly due the big differences 
between Rails and Django models. As Django migrations are derived from the 
current model state so there’s no way I can think of to express “make this 
auto-generated field a BigAutoField only if this model is new”. The way I see 
it is that a global setting is very easy to toggle and there is little chance 
of missing the large numbers of migrations that would be generated during the 
Django update. Smaller applications could apply the migrations with little 
issue and larger applications would be able to opt-out (as well as be reminded 
that this is a problem they could face!).

Some specifics:
- 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
- The setting would also be used for GenericForeignKeys, which right now are 
backed by a PositiveIntegerField and so suffer from the same AutoField 
limitations

Any thoughts on this?

Tom

1. https://groups.google.com/d/msg/django-developers/imBJwRrtJkk/P4g0Y87lAgAJ 


2. https://github.com/django/django/pull/8924/ 


3. https://code.djangoproject.com/ticket/56 




-- 
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/435EC704-3EF6-4EF4-BF85-175AE29C01F5%40tomforb.es.

Re: Management of static assets

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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 has something like response.scripts and response.styles 
where you introspect and attach or remove stuff along the way.

Typically, if two different apps ship their own jquery.js then things are not 
going to work, one jquery will override the other and plugins will not be 
registered anymore.

So in Cubic at least your lib can check if there's a jquery js prior to adding 
your own. It's no silver bullet though.

-- 
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/dncgO1IUgyjWRJ9fMMbHWh5L9W5VfmgNgwyP9BNo2w11wdNAtZ8JZEH6bH61i-1o3kC_iPKx0ptXGMexpUQFC1u4oG13VEdA7xg0RX3Lw0U%3D%40protonmail.com.

Re: queryset.iterator() and prefetch_related()

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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 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/dmzUJkHwxaO0lX-CL3B2TbDhPGhJOcG7kmB7HJ3SNF72m8FieDM1HPnb3KprQXNJyClLisOe5awCBMqlAbnkkFwfV6ML73UzHLe9zpr1P7w%3D%40protonmail.com.

Re: queryset.iterator() and prefetch_related()

[charettes]

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 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 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/3e361ef0-179d-45dd-894b-38acd9fd4a9ao%40googlegroups.com.

Re: queryset.iterator() and prefetch_related()

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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 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/VkC5P_eBfbOxnWPqdUhdiUVp02eT4qwfpQA6meIJsSASKaO1Djn3HTgAGf9XmB6E5xri7k73YYpeLooI0tveTT2YkgPwnnp69I6vpPx_WDA%3D%40protonmail.com.

Re: queryset.iterator() and prefetch_related()

[charettes]

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 08:59:09 UTC-4, 1337 Shadow Hacker a écrit :
>
> 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 <
> 1337s...@protonmail.com > a écrit :
>
> Sorry I sent the mail prior to finishing, redoing fully from here: 
>
> I notice a piece of code inside ModelChoiceIterator that seems to keep 
> going a bit back and forth, currently it looks like this:
>
> # Can't use iterator() when queryset uses prefetch_related()
> if not queryset._prefetch_related_lookups:
> queryset = queryset.iterator()
>
> But before it looked like this:
>
> # Can't use iterator() when queryset uses prefetch_related()
> if not queryset._prefetch_related_lookups and 
> queryset._result_cache is None:
>  queryset = queryset.iterator()
>
> Anyway, if you want to implement your own QuerySet class from scratch, 
> which is the case of django-querysetsequence, and that's pretty useful to 
> feed ModelChoiceFields, as long as you prefix object ids with content type 
> ids which is pretty trivial.
>
> Do you think it would be acceptable to start an effort with the objective 
> of making django.forms.models rely purely on a public API of QuerySet ?
>
> In this case, how would you accept to see that changed ?
>
> Thanks in advance
>
> 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 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/831990fa-95fa-421a-a61a-95b1097cf8f6o%40googlegroups.com.

Re: queryset.iterator() and prefetch_related()

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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 
<1337sha...@protonmail.com> a écrit :

> Sorry I sent the mail prior to finishing, redoing fully from here:
>
> I notice a piece of code inside ModelChoiceIterator that seems to keep going 
> a bit back and forth, currently it looks like this:
>
> # Can't use iterator() when queryset uses prefetch_related()
> if not queryset._prefetch_related_lookups:
> queryset = queryset.iterator()
>
> But before it looked like this:
>
> # Can't use iterator() when queryset uses prefetch_related()
> if not queryset._prefetch_related_lookups and queryset._result_cache is None:
> queryset = queryset.iterator()
>
> Anyway, if you want to implement your own QuerySet class from scratch, which 
> is the case of django-querysetsequence, and that's pretty useful to feed 
> ModelChoiceFields, as long as you prefix object ids with content type ids 
> which is pretty trivial.
>
> Do you think it would be acceptable to start an effort with the objective of 
> making django.forms.models rely purely on a public API of QuerySet ?
>
> In this case, how would you accept to see that changed ?
>
> Thanks in advance
>
> 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 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/qRlEqcCtLHKcogJ3Q8-tEeDcagPTd8XtyQqaPtBj9BM_kNTU3pIGwVnFSmlu_TbA0dQYmSjNc1_CCUjL_gYNvu-cD4lM1tkNcMxtJIKkQwM%3D%40protonmail.com.