Funktioniert select_related für GenericRelation-Beziehungen oder gibt es eine sinnvolle Alternative? Im Moment ruft Django individuelle SQL-Aufrufe für jedes Element in meinem Abfrage-Set auf, und ich möchte vermeiden, dass etwas wie select_related verwendet wird.
%Vor%Ich wähle eine Reihe von Claims aus und möchte, dass die zugehörigen Proofs einzeln abgerufen und nicht einzeln abgefragt werden.
Sieht aus wie select_related und GRs funktionieren nicht zusammen . Ich schätze, du könntest eine Art Accessor für Claim schreiben, der sie alle über dieselbe Abfrage erhält. Dieser Post gibt Ihnen einige Hinweise auf Raw-SQL, um generische Objekte zu erhalten, wenn Sie brauchen sie
Es gibt keine integrierte Möglichkeit, dies zu tun. Aber ich habe eine Technik zur Simulation von select_related auf generische Relationen gepostet in meinem Blog .
Blog-Inhalt zusammengefasst:
Wir können Djangos _content_object_cache -Feld verwenden, um im Wesentlichen unsere eigene select_related für generische Beziehungen zu erstellen.
Hier erhalten wir alle verschiedenen Inhaltstypen, die von den Beziehungen verwendet werden im Abfrage-Set und dann die Menge der eindeutigen Objekt-IDs für jedes Verwenden Sie die integrierte Methode in_bulk manager, um alle Inhaltstypen abzurufen sofort in einem netten gebrauchsfertigen Wörterbuch mit ID. Dann machen wir eins Abfrage nach Inhaltstyp, wieder mit in_bulk, um alle tatsächlichen zu erhalten Objekt.
Schließlich setzen wir einfach das relevante Objekt auf die _content_object_cache Feld des Quellelements. Der Grund dafür ist, dass dies das Attribut ist, das Django überprüfen würde, und wenn ja notwendig, wenn Sie x.content_object direkt aufgerufen haben. Durch Vorbevölkern Wir stellen sicher, dass Django niemals die Person anrufen muss Nachschlagen - in der Tat, was wir tun, ist eine Art von select_related () für generische Beziehungen.
Sie können die .extra () -Funktion verwenden, um Felder manuell zu extrahieren:
%Vor%Das .filter () führt den Join aus, das .extra () zieht ein Feld. proof_proof ist der SQL-Tabellenname für das Proof-Modell. Wenn Sie mehr als ein Feld benötigen, geben Sie jedes im Wörterbuch an.
Tags und Links django django-orm