始终像在Django Admin中的raw_id_fields一样处理ForeignKey字段

Question

在我的项目中，这种情况发生得太频繁了：

• 有人添加了一个名为Foo的模型，其中包含多个ForeignKey字段，其中一个字段引用了模型Bar
• 管理员为该模型添加并工作正常
• 将代码部署到生产服务器上
• 在生产服务器上，Bar有数百万个实例
• 有人访问Foo的管理页面； Django尝试一次性检索所有Bar（以在组合框中显示它们），服务器负载过高
• 稍后通过编辑Foo管理程序并将bar添加到raw_id_fields来解决问题。

我想防止将来发生这种情况，最好是通过某种方式声明（一劳永逸）Bar有很多行，并且应始终像列出对其引用的字段一样在所有管理页面中进行处理。是否可能做到这一点？

- Kos

Answer 1

这是一个很好的观点。这是一个关键问题，可能会使数据库甚至Web服务器崩溃。

考虑到这一点，我认为默认方法必须是raw_id_fields。如果你知道你在做什么，那么你可以改变这个行为。

不幸的是，大多数管理界面库的作者都不同意这种想法。不仅对于Python-Django，而且对于其他社区如Ruby-Rails也是如此。

5年前，我厌倦了同样的问题，然后开发了django-smart-autoregister，它可以做到这一点，并使用另一种好的模式进行自动配置。即使今天我仍然面临这个问题，所以我想值得一看。 ps：该库最初采用模块化方法实现，尽管您只需调用一些函数，它就会根据模型字段为您配置raw_id_fields。

- Paulo Cheque

Answer 2

来自文档：

ForeignKey 由 django.forms.ModelChoiceField 表示，它是一个 ChoiceField，其选项是模型 QuerySet。

ModelChoiceField 扩展了 Field，并且具有可以被滥用的 widget 属性https://github.com/django/django/blob/master/django/forms/fields.py#L49

在项目文件中的某个位置添加此内容。

from django.forms import ModelChoiceField
from django.contrib.admin.widgets import ForeignKeyRawIdWidget
ModelChoiceField.widget = ForeignKeyRawIdWidget

缺点：这也会发生在非管理员表单上

- Francis Yaconiello

---

嗯，这是一个不错的起点 - 现在也许可以让ModelAdmin在创建其ModelForm时有选择地使用该小部件。 - Kos