Well, I did personally encounter this issue more than a couple times on several projects. In most cases simply switching to raw id or read only where required works fine however it does add additional maintenance overhead for projects that started small and at some point database grows and some admin pages stop working. I even had to write some custom code once when a client wanted to keep the default select interface but there were too many of those selects with the same options for some objects (different number of inlines IIRC), I basically added some js code to make sure the generation and transmission of the list only takes place once. Ah, another part of the problem was that by default every single object is iterated and passed to force_text (I think) and that was costly and there wasn't an obvious way to use, like, a combination of model fields instead. Maybe some internals got changed recently and it got better though, I didn't review these parts of django code in a while.
That being said, I do see a value in using the default select sometimes (aforementioned small configuration tables are a good example) and I did see a lot of frustration when people see otherwise nice interface failing miserably just because some new user accounts or other data was added. I'm not sure forcing raw id is the right way to handle this but doing something that works by default (i.e. without you having to write a custom admin class or even form) regardless of table size would be a good idea. How about some field that intelligently guesses the table size and looks either like default select or like raw id field depending on that? A COUNT(*) query is usually much less costly than fetching the whole table and doing things with it. Additional (and simple enough) optimization could be done by making sure options for the same queryset on multiple fields or formset forms are only generated once, maybe we could cache them somewhere in the modelform/formset objects? Also, although it might be obvious and even documented somewhere that __str__() method shouldn't perform additional db queries if you expect to use string coercion on a bunch of objects (actually I don't know if it is documented at all, I just hope so, correct me if I'm wrong), maybe some simple way to override string coercion method for the options and in similar places where a bunch of objects has to be converted to a list of strings could be a good idea (possibly on model/queryset level, some attribute or method that modelform would pick up and use to make lighter values() query instead of the default fetching, instantiation, coercion). I'm not sure what particular solution would be the best here though or I would've proposed one already, but it definitely shouldn't however be complicated or require much customization (if you need something complicated and customized you can always customize forms and fields and it stops being a problem), it should be something simple and effective for when you prefer to use the default classes wherever possible. Ivan. On Sun, Oct 21, 2018 at 10:48 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > The default <select> widget is fine for configuration tables with no more > than a few dozen values. > > In my experience, I rarely encountered use cases for editing foreign keys > to very large tables in the admin. > > Readonly or autocomplete are good choices. > > Best regards, > > -- > Aymeric. > > > > On 17 Oct 2018, at 17:59, Yo-Yo Ma <baxterstock...@gmail.com> wrote: > > I have yet to ever come across a situation where the default <select> > 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 <option value="..."> 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 <select> 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 > <https://groups.google.com/d/msgid/django-developers/76e35c9d-b62f-498f-a382-6f12f74ebd98%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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/BF6BF10C-BFCE-47FE-A492-EF5B671E1039%40polytechnique.org > <https://groups.google.com/d/msgid/django-developers/BF6BF10C-BFCE-47FE-A492-EF5B671E1039%40polytechnique.org?utm_medium=email&utm_source=footer> > . > 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/CADPNjZ4eCVCh30nT-U9YrevFA61eNJLPM20TZTmuap1yriM1-g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
