Ce scénario arrive trop souvent dans mon projet:
FOO qui comporte plusieurs champs Fore FoundeyKey , l'un d'entre eux pour faire référence au modèle bar
- Un administrateur est ajouté pour ce modèle (et fonctionne OK)
- Le code est déployé
- sur le serveur de production,
bar a des millions d'instances
- Quelqu'un accède à une page d'administration FOO ; Django tente de récupérer tout s à la fois (pour les afficher dans une liste déroulante) et le serveur est surchargé
- Plus tard, le problème est corrigé en modifiant
Admin S et ajoutant bar à brut_id_fields . .
J'aimerais empêcher cette situation de se produire à l'avenir, de préférence en quelque sorte en indiquant (une fois pour toutes) que bar a de nombreuses lignes et il devrait être toujours Traité comme si le champ faisant référence à celui-ci a été répertorié dans Raw_id_fields dans toutes les pages d'administration. Est-ce possible?
3 Réponses :
de la DOCS:
FortressKey est représenté par Django.Forms.Modelchoicefield, qui est un ChoiceField dont les choix sont un modèle de requête. P> blockQuote>
ModelChoicefield étend le champ, et là-bas a une propriété de widget pouvant être abusée https://github.com/django/django/blob /master/django/forms/fields.py#l49 p>
Ajoutez ceci quelque part dans vos fichiers de projet. P>
from django.forms import ModelChoiceField from django.contrib.admin.widgets import ForeignKeyRawIdWidget ModelChoiceField.widget = ForeignKeyRawIdWidget
Hmm, c'est un bon point de départ - maintenant peut-être peut-être que Modeladmin utilise ce widget sélectivement lors de la création de son modelform.
Vous pouvez probablement faire quelque chose comme ceci:
class SomeAdmin(somewhere.MyModelAdmin):
model = SomeModel
C'est un point d'excellence. Ceci est un problème critique qui peut refuser la base de données et même le serveur Web.
Considérant cela, je pense que l'approche par défaut doit être le Malheureusement, la plupart des auteurs des bibliothèques d'interfaces administrateurs sont en désaccord de cette pensée. Pas seulement pour Python-Django, mais aussi pour d'autres communautés telles que Ruby-Rails.
Il y a 5 ans, je me suis fatigué d'avoir le même problème, puis j'ai développé le Django-Smart- Autorégisterie , cela fait cela et configurez également automatiquement à l'aide d'un autre bon modèles. Même aujourd'hui, je fais face à ce problème, alors je suppose que cela vaut la peine de jeter un coup d'œil.
PS: la bibliothèque a été mise en œuvre à l'origine à l'aide d'une approche modulaire, bien que vous appelez simplement certaines fonctions qui configurent le brut_id_fields chose. Si vous savez ce que vous faites, vous modifiez ce comportement.
brut_id_fields pour vous en fonction du champ modèle.