Make `raw_id_fields` the default functionality in the admin

2018-10-17 Thread Yo-Yo Ma 

I have yet to ever come across a situation where the default  field 
is more useful than the raw ID field, pertaining foreign key fields in the 
admin.

I have, however, personally witnessed a major publishing company bring 
their production app servers to a halt (out of memory) due to Django 
attempting to generate 2.5 million  tags for some dozen 
admins that were all refreshing an admin changeview, wondering why it was 
taking so long to load.

Another thing worth noting is that when the  is most useful (when 
there are very few records to select) also happens to be when the raw ID 
field is most easily used (since the selection changelist only contains the 
same very few records). IOW, the raw ID field's usefulness is universal, 
working well with just a few records, and also working well (due to search 
/ sort) when there are many records.

Nary a transition would be required, since the `raw_id_fields` could simply 
be ignored.

A new `select_fields = []` could be added for those who wish to easily  use 
the old functionality.

Is there any reason why this couldn't or shouldn't be done?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/76e35c9d-b62f-498f-a382-6f12f74ebd98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make `raw_id_fields` the default functionality in the admin

2018-10-17 Thread Yo-Yo Ma 
One last note: M2M could also benefit from this, and could continue to look 
for `filter_horizontal` and not use a raw IDs field in those cases.

On Wednesday, October 17, 2018 at 11:59:43 AM UTC-4, Yo-Yo Ma wrote:
>
> I have yet to ever come across a situation where the default  
> field is more useful than the raw ID field, pertaining foreign key fields 
> in the admin.
>
> I have, however, personally witnessed a major publishing company bring 
> their production app servers to a halt (out of memory) due to Django 
> attempting to generate 2.5 million  tags for some dozen 
> admins that were all refreshing an admin changeview, wondering why it was 
> taking so long to load.
>
> Another thing worth noting is that when the  is most useful (when 
> there are very few records to select) also happens to be when the raw ID 
> field is most easily used (since the selection changelist only contains the 
> same very few records). IOW, the raw ID field's usefulness is universal, 
> working well with just a few records, and also working well (due to search 
> / sort) when there are many records.
>
> Nary a transition would be required, since the `raw_id_fields` could 
> simply be ignored.
>
> A new `select_fields = []` could be added for those who wish to easily  
> use the old functionality.
>
> Is there any reason why this couldn't or shouldn't be done?
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e0262150-ec7e-487d-8fb1-b64f8df2e7a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make `raw_id_fields` the default functionality in the admin

2018-10-17 Thread Collin Anderson 
raw_id_fields can be a bit confusing to people. Have you tried the new
autocomplete_fields? It's almost as easy to use as a select field, and it
should help solve the problem. However, it's not as easy to make the
default (because it requires specifying search_fields on the related model)

On Wed, Oct 17, 2018 at 12:02 PM Yo-Yo Ma  wrote:

> One last note: M2M could also benefit from this, and could continue to
> look for `filter_horizontal` and not use a raw IDs field in those cases.
>
> On Wednesday, October 17, 2018 at 11:59:43 AM UTC-4, Yo-Yo Ma wrote:
>>
>> I have yet to ever come across a situation where the default 
>> field is more useful than the raw ID field, pertaining foreign key fields
>> in the admin.
>>
>> I have, however, personally witnessed a major publishing company bring
>> their production app servers to a halt (out of memory) due to Django
>> attempting to generate 2.5 million  tags for some dozen
>> admins that were all refreshing an admin changeview, wondering why it was
>> taking so long to load.
>>
>> Another thing worth noting is that when the  is most useful (when
>> there are very few records to select) also happens to be when the raw ID
>> field is most easily used (since the selection changelist only contains the
>> same very few records). IOW, the raw ID field's usefulness is universal,
>> working well with just a few records, and also working well (due to search
>> / sort) when there are many records.
>>
>> Nary a transition would be required, since the `raw_id_fields` could
>> simply be ignored.
>>
>> A new `select_fields = []` could be added for those who wish to easily
>> use the old functionality.
>>
>> Is there any reason why this couldn't or shouldn't be done?
>>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e0262150-ec7e-487d-8fb1-b64f8df2e7a3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S4kK_D5c8MbE3OHDhsNcrpuTJpLBfbx79hD%2BS-DDnjdTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.