Relationships API¶

Objektname	Beschreibung
backref(name, **kwargs)	Wenn der Parameter `relationship.backref` verwendet wird, werden spezifische Parameter bereitgestellt, die bei der Generierung der neuen `relationship()` verwendet werden.
dynamic_loader([argument], **kw)	Konstruiert eine dynamisch ladende Mapper-Eigenschaft.
foreign(expr)	Annotiert einen Teil eines Primaryjoin-Ausdrucks mit einer ‚foreign‘-Annotation.
relationship([argument, secondary], , [uselist, collection_class, primaryjoin, secondaryjoin, back_populates, order_by, backref, overlaps, post_update, cascade, viewonly, init, repr, default, default_factory, compare, kw_only, hash, lazy, passive_deletes, passive_updates, active_history, enable_typechecks, foreign_keys, remote_side, join_depth, comparator_factory, single_parent, innerjoin, distinct_target_key, load_on_pending, query_class, info, omit_join, sync_backref], *kw)	Stellt eine Beziehung zwischen zwei zugeordneten Klassen bereit.
remote(expr)	Annotiert einen Teil eines Primaryjoin-Ausdrucks mit einer ‚remote‘-Annotation.

function sqlalchemy.orm.relationship(argument: _RelationshipArgumentType[Any] | None = None, secondary: _RelationshipSecondaryArgument | None = None, *, uselist: bool | None = None, collection_class: Type[Collection[Any]] | Callable[[], Collection[Any]] | None = None, primaryjoin: _RelationshipJoinConditionArgument | None = None, secondaryjoin: _RelationshipJoinConditionArgument | None = None, back_populates: str | None = None, order_by: _ORMOrderByArgument = False, backref: ORMBackrefArgument | None = None, overlaps: str | None = None, post_update: bool = False, cascade: str = 'save-update, merge', viewonly: bool = False, init: _NoArg | bool = _NoArg.NO_ARG, repr: _NoArg | bool = _NoArg.NO_ARG, default: _NoArg | _T = _NoArg.NO_ARG, default_factory: _NoArg | Callable[[], _T] = _NoArg.NO_ARG, compare: _NoArg | bool = _NoArg.NO_ARG, kw_only: _NoArg | bool = _NoArg.NO_ARG, hash: _NoArg | bool | None = _NoArg.NO_ARG, lazy: _LazyLoadArgumentType = 'select', passive_deletes: Literal['all'] | bool = False, passive_updates: bool = True, active_history: bool = False, enable_typechecks: bool = True, foreign_keys: _ORMColCollectionArgument | None = None, remote_side: _ORMColCollectionArgument | None = None, join_depth: int | None = None, comparator_factory: Type[RelationshipProperty.Comparator[Any]] | None = None, single_parent: bool = False, innerjoin: bool = False, distinct_target_key: bool | None = None, load_on_pending: bool = False, query_class: Type[Query[Any]] | None = None, info: _InfoType | None = None, omit_join: Literal[None, False] = None, sync_backref: bool | None = None, **kw: Any) → _RelationshipDeclared[Any]¶

Stellt eine Beziehung zwischen zwei zugeordneten Klassen bereit.

Dies entspricht einer Eltern-Kind- oder einer Verknüpfungstabelle. Die konstruierte Klasse ist eine Instanz von Relationship.

Siehe auch

Arbeiten mit ORM-bezogenen Objekten - Tutorial-Einführung in relationship() im SQLAlchemy Unified Tutorial

Konfiguration von Beziehungen - Narrative Dokumentation

Parameter:

argument¶ –
Dieser Parameter bezieht sich auf die Klasse, die mit der anderen Klasse in Beziehung gesetzt werden soll. Er akzeptiert verschiedene Formen, darunter eine direkte Referenz auf die Zielklasse selbst, die Mapper-Instanz für die Zielklasse, eine Python-Callable/Lambda, die eine Referenz auf die Klasse oder Mapper zurückgibt, wenn sie aufgerufen wird, und schließlich einen Zeichenkettennamen für die Klasse, der aus der verwendeten registry aufgelöst wird, um die Klasse zu finden, z.B.
```
class SomeClass(Base):
    # ...

    related = relationship("RelatedClass")
```
Das relationship.argument kann auch vollständig aus dem relationship()-Konstrukt weggelassen und stattdessen auf der linken Seite in eine Mapped-Annotation eingefügt werden, die einen Python-Sammlungstyp enthalten sollte, wenn die Beziehung als Sammlung erwartet wird, wie z.B.
```
class SomeClass(Base):
    # ...

    related_items: Mapped[List["RelatedItem"]] = relationship()
```
Oder für eine Many-to-One- oder One-to-One-Beziehung
```
class SomeClass(Base):
    # ...

    related_item: Mapped["RelatedItem"] = relationship()
```
Siehe auch

Definieren von zugeordneten Eigenschaften mit Declarative - weitere Details zur Konfiguration von Beziehungen bei Verwendung von Declarative.
secondary¶ –
Für eine Many-to-Many-Beziehung gibt sie die Zwischentabelle an und ist typischerweise eine Instanz von Table. In selteneren Fällen kann das Argument auch als Alias-Konstrukt oder sogar als Join-Konstrukt angegeben werden.

relationship.secondary kann auch als aufrufbare Funktion übergeben werden, die zur Initialisierungszeit des Mappers ausgewertet wird. Bei Verwendung von Declarative kann es sich auch um ein Zeichenkettenargument handeln, das den Namen einer Table angibt, die in der Metadatensammlung vorhanden ist, die der übergeordneten zugeordneten Table zugeordnet ist.

Warnung

Wenn als Python-auswertbarer String übergeben, wird das Argument mithilfe der eval()-Funktion von Python interpretiert. **GEBEN SIE KEINE UNVERTRAUTEN EINGABEN AN DIESEN STRING WEITER**. Siehe Auswertung von Beziehungsargumenten für Details zur deklarativen Auswertung von relationship()-Argumenten.

Das Schlüsselwortargument relationship.secondary wird typischerweise in dem Fall angewendet, wenn die Zwischentabelle Table nicht anderweitig in einer direkten Klassenzuordnung ausgedrückt wird. Wenn die "sekundäre" Tabelle auch woanders explizit zugeordnet ist (z.B. wie in Assoziationsobjekt), sollte man in Erwägung ziehen, das Flag relationship.viewonly anzuwenden, damit diese relationship() nicht für Persistenzoperationen verwendet wird, die mit denen des Assoziationsobjekt-Musters in Konflikt geraten könnten.

Siehe auch

Many-to-Many - Referenzbeispiel für "Many-to-Many".

Selbstreferentielle Many-to-Many-Beziehung - Einzelheiten zur Verwendung von Many-to-Many in einem selbstreferenziellen Fall.

Konfiguration von Many-to-Many-Beziehungen - Zusätzliche Optionen bei Verwendung von Declarative.

Assoziationsobjekt - eine Alternative zu relationship.secondary bei der Zusammensetzung von Verknüpfungstabellen-Beziehungen, die es ermöglicht, zusätzliche Attribute auf der Verknüpfungstabelle zu spezifizieren.

Komplexe sekundäre Joins - ein weniger genutztes Muster, das in einigen Fällen die Verwendung komplexer relationship() SQL-Bedingungen ermöglicht.
active_history=False¶ – Wenn True, gibt an, dass der "vorherige" Wert für eine Many-to-One-Referenz geladen werden soll, wenn er ersetzt wird und noch nicht geladen wurde. Normalerweise müssen die History-Tracking-Logiken für einfache Many-to-One-Beziehungen nur den "neuen" Wert kennen, um einen Flush durchzuführen. Dieses Flag ist für Anwendungen verfügbar, die get_history() verwenden und auch den "vorherigen" Wert des Attributs kennen müssen.
backref¶ –
Eine Referenz auf einen Zeichenketten-Beziehungsnamen oder ein backref()-Konstrukt, das verwendet wird, um automatisch eine neue relationship() auf der zugehörigen Klasse zu generieren, die dann mithilfe einer bidirektionalen relationship.back_populates-Konfiguration auf diese verweist.

In modernem Python ist die explizite Verwendung von relationship() mit relationship.back_populates vorzuziehen, da es in Bezug auf die Mapper-Konfiguration robuster und konzeptionell einfacher ist. Es integriert sich auch mit neuen PEP 484-Typisierungsfunktionen, die in SQLAlchemy 2.0 eingeführt wurden und mit dynamisch generierten Attributen nicht möglich sind.

Siehe auch

Verwendung des Legacy-Parameters ‚backref‘ für Beziehungen - Hinweise zur Verwendung von relationship.backref

Arbeiten mit ORM-bezogenen Objekten - im SQLAlchemy Unified Tutorial, präsentiert eine Übersicht über die bidirektionale Beziehungsgestaltung und das Verhalten unter Verwendung von relationship.back_populates

backref() - ermöglicht die Steuerung der Konfiguration von relationship() bei Verwendung von relationship.backref.
back_populates¶ –
Gibt den Namen einer relationship() auf der zugehörigen Klasse an, die mit dieser synchronisiert wird. Es wird normalerweise erwartet, dass die relationship() auf der zugehörigen Klasse ebenfalls auf diese verweist. Dies ermöglicht es Objekten auf beiden Seiten jeder relationship(), In-Python-Zustandsänderungen zu synchronisieren, und liefert auch Direktiven an den Unit of Work Flush-Prozess, wie Änderungen entlang dieser Beziehungen gespeichert werden sollen.

Siehe auch

Arbeiten mit ORM-bezogenen Objekten - im SQLAlchemy Unified Tutorial, präsentiert eine Übersicht über die bidirektionale Beziehungsgestaltung und das Verhalten.

Grundlegende Beziehungsmodelle - enthält viele Beispiele für relationship.back_populates.

relationship.backref - Legacy-Form, die eine prägnantere Konfiguration ermöglicht, aber keine explizite Typisierung unterstützt
overlaps¶ –
Ein Zeichenkettenname oder ein durch Kommas getrenntes Set von Namen anderer Beziehungen auf diesem Mapper, einem abgeleiteten Mapper oder einem Zielmapper, mit denen diese Beziehung beim Persistieren auf dieselben Fremdschlüssel schreiben kann. Die einzige Auswirkung ist, dass die Warnung, dass diese Beziehung mit einer anderen beim Persistieren in Konflikt gerät, eliminiert wird. Dies wird für solche Beziehungen verwendet, die wirklich in der Lage sind, miteinander in Konflikt zu geraten, aber die Anwendung stellt sicher, dass keine solchen Konflikte auftreten.

Neu in Version 1.4.

Siehe auch

Beziehung X kopiert Spalte Q nach Spalte P, was mit Beziehung(en) in Konflikt steht: ‘Y’ - Anwendungsbeispiel
cascade¶ –
Eine durch Kommas getrennte Liste von Cascade-Regeln, die bestimmen, wie Session-Operationen von Eltern zu Kind "kaskadiert" werden sollen. Dies hat standardmäßig False, was bedeutet, dass die Standard-Cascade verwendet werden soll – diese Standard-Cascade ist "save-update, merge".

Die verfügbaren Cascades sind save-update, merge, expunge, delete, delete-orphan und refresh-expire. Eine zusätzliche Option, all, ist eine Kurzschreibweise für "save-update, merge, refresh-expire, expunge, delete" und wird oft verwendet wie in "all, delete-orphan", um anzugeben, dass zugehörige Objekte den Elternobjekten in allen Fällen folgen und gelöscht werden sollen, wenn sie entfernt werden.

Siehe auch

Cascades - Vollständige Details zu jeder der verfügbaren Cascade-Optionen.
cascade_backrefs=False¶ –
Legacy; dieses Flag ist immer False.

Geändert in Version 2.0: Die Funktionalität "cascade_backrefs" wurde entfernt.
collection_class¶ –
Eine Klasse oder ein Callable, das ein neues Listenobjekt zurückgibt. wird anstelle einer einfachen Liste zur Speicherung von Elementen verwendet.

Siehe auch

Anpassen von Sammlungzugriffen - Einführende Dokumentation und Beispiele.
comparator_factory¶ –
Eine Klasse, die von Comparator erbt und eine benutzerdefinierte SQL-Klauselgenerierung für Vergleichsoperationen bereitstellt.

Siehe auch

PropComparator - einige Details zur Neudefinition von Comparators auf dieser Ebene.

Operatoranpassung - Kurze Einführung in diese Funktion.
distinct_target_key=None¶ –
Gibt an, ob bei einer "subquery" Eager-Ladung das DISTINCT-Schlüsselwort auf die innerste SELECT-Anweisung angewendet werden soll. Wenn auf None gesetzt, wird das DISTINCT-Schlüsselwort in Fällen angewendet, in denen die Zielspalten nicht den vollständigen Primärschlüssel der Zieltabelle umfassen. Wenn auf True gesetzt, wird das DISTINCT-Schlüsselwort bedingungslos auf die innerste SELECT-Anweisung angewendet.

Es kann wünschenswert sein, dieses Flag auf False zu setzen, wenn DISTINCT die Leistung der innersten Subquery über das hinaus reduziert, was doppelte innere Zeilen verursachen könnten.

Siehe auch

Relationship Loading Techniques - enthält eine Einführung in die Subquery-Eager-Ladung.
doc¶ – Docstring, der auf den resultierenden Deskriptor angewendet wird.
foreign_keys¶ –
Eine Liste von Spalten, die als "Fremdschlüssel"-Spalten verwendet werden sollen, oder Spalten, die auf den Wert einer entfernten Spalte verweisen, im Kontext dieses relationship()-Objekts relationship.primaryjoin-Bedingung. Das heißt, wenn die relationship.primaryjoin-Bedingung dieses relationship() a.id == b.a_id lautet und die Werte in b.a_id in a.id vorhanden sein müssen, dann ist die "Fremdschlüssel"-Spalte dieses relationship() b.a_id.

In normalen Fällen ist der Parameter relationship.foreign_keys **nicht erforderlich.** relationship() bestimmt automatisch, welche Spalten in der relationship.primaryjoin-Bedingung als "Fremdschlüssel"-Spalten betrachtet werden sollen, basierend auf den Column-Objekten, die ForeignKey angeben oder anderweitig als referenzierende Spalten in einem ForeignKeyConstraint-Konstrukt aufgeführt sind. relationship.foreign_keys ist nur erforderlich, wenn
1. Es mehr als eine Möglichkeit gibt, eine Verbindung von der lokalen Tabelle zur entfernten Tabelle herzustellen, da mehrere Fremdschlüsselreferenzen vorhanden sind. Wenn foreign_keys gesetzt wird, wird relationship() nur die hier angegebenen Spalten als "fremd" betrachten.
2. Die zu mappende Table keine ForeignKey- oder ForeignKeyConstraint-Konstrukte enthält, oft weil die Tabelle aus einer Datenbank reflektiert wurde, die keine Fremdschlüsselreflexion unterstützt (MySQL MyISAM).
3. Das Argument relationship.primaryjoin wird verwendet, um eine nicht standardmäßige Join-Bedingung zu erstellen, die Spalten oder Ausdrücke verwendet, die sich normalerweise nicht auf ihre "Eltern"-Spalte beziehen, wie z. B. eine Join-Bedingung, die durch einen komplexen Vergleich mit einer SQL-Funktion ausgedrückt wird.
Das relationship()-Konstrukt löst aussagekräftige Fehlermeldungen aus, die die Verwendung des Parameters relationship.foreign_keys bei mehrdeutigen Bedingungen vorschlagen. In typischen Fällen, wenn relationship() keine Ausnahmen auslöst, ist der Parameter relationship.foreign_keys normalerweise nicht erforderlich.

relationship.foreign_keys kann auch als aufrufbare Funktion übergeben werden, die zur Initialisierungszeit des Mappers ausgewertet wird, und kann als Python-auswertbarer String übergeben werden, wenn Declarative verwendet wird.

Warnung

Wenn als Python-auswertbarer String übergeben, wird das Argument mithilfe der eval()-Funktion von Python interpretiert. **GEBEN SIE KEINE UNVERTRAUTEN EINGABEN AN DIESEN STRING WEITER**. Siehe Auswertung von Beziehungsargumenten für Details zur deklarativen Auswertung von relationship()-Argumenten.

Siehe auch

Behandlung mehrerer Verknüpfungswege

Erstellung benutzerdefinierter Fremdschlüsselbedingungen

foreign() - ermöglicht die direkte Annotation der "fremden" Spalten innerhalb einer relationship.primaryjoin-Bedingung.
info¶ – Optionales Datenverzeichnis, das in das Attribut MapperProperty.info dieses Objekts eingefügt wird.
innerjoin=False¶ –
Wenn True, verwenden Joined Eager Loads einen INNER JOIN, um sich mit verwandten Tabellen zu verbinden, anstatt eines OUTER JOIN. Der Zweck dieser Option liegt im Allgemeinen in der Leistung, da INNER JOINs im Allgemeinen besser performen als OUTER JOINs.

Dieses Flag kann auf True gesetzt werden, wenn die Beziehung über einen Many-to-One-Zugriff mit lokalen Fremdschlüsseln referenziert, die nicht nullbar sind, oder wenn die Referenz One-to-One oder eine Sammlung ist, die garantiert einen oder mindestens einen Eintrag hat.

Die Option unterstützt dieselben "verschachtelten" und "nicht verschachtelten" Optionen wie joinedload.innerjoin. Siehe dieses Flag für Details zu verschachtelten/nicht verschachtelten Verhaltensweisen.

Siehe auch

joinedload.innerjoin - die Option, wie sie vom Lader konfiguriert wurde, einschließlich Details zum Verschachtelungsverhalten.

Welche Art von Ladevorgang verwenden? - Diskussion einiger Details verschiedener Laderoptionen.
join_depth¶ –
Wenn nicht None, ein Ganzzahlwert, der angibt, wie viele Ebenen tief "Eager"-Lader bei einer selbst referenzierenden oder zyklischen Beziehung joinen sollen. Die Zahl zählt, wie oft derselbe Mapper in der Ladebedingung entlang eines bestimmten Join-Zweigs vorhanden ist. Wenn der Standardwert None beibehalten wird, stoppen Eager-Lader die Verkettung, wenn sie auf denselben Zielmapper stoßen, der bereits höher in der Kette ist. Diese Option gilt sowohl für Joined- als auch für Subquery-Eager-Lader.

Siehe auch

Konfigurieren von selbst referenzierender Eager-Ladung - Einführung in Dokumentation und Beispiele.
lazy='select'¶ –
spezifiziert, wie die verwandten Elemente geladen werden sollen. Der Standardwert ist select. Werte beinhalten
- select - Elemente sollen träge geladen werden, wenn auf die Eigenschaft zum ersten Mal zugegriffen wird, mit einer separaten SELECT-Anweisung oder Identitätskartenabruf für einfache Many-to-One-Referenzen.
- immediate - Elemente sollen beim Laden der Eltern geladen werden, mit einer separaten SELECT-Anweisung oder Identitätskartenabruf für einfache Many-to-One-Referenzen.
- joined - Elemente sollen "eager" in derselben Abfrage wie die Eltern geladen werden, mit einem JOIN oder LEFT OUTER JOIN. Ob der Join "outer" ist, wird durch den Parameter relationship.innerjoin bestimmt.
- subquery - Elemente sollen "eager" beim Laden der Eltern geladen werden, mit einer zusätzlichen SQL-Anweisung, die einen JOIN zu einer Subquery der ursprünglichen Anweisung für jede angeforderte Sammlung ausgibt.
- selectin - Elemente sollen "eager" beim Laden der Eltern geladen werden, mit einer oder mehreren zusätzlichen SQL-Anweisungen, die einen JOIN zum unmittelbaren Elternobjekt ausgeben und Primärschlüssel-Identifikatoren mit einer IN-Klausel angeben.
- noload - zu keinem Zeitpunkt soll eine Ladung erfolgen. Die verwandte Sammlung bleibt leer. Die Strategie noload wird für den allgemeinen Gebrauch nicht empfohlen. Für einen allgemeinen Ansatz "nie laden" siehe Write-Only-Beziehungen
- raise - träges Laden ist nicht erlaubt; der Zugriff auf das Attribut, wenn sein Wert nicht bereits durch Eager-Ladung geladen wurde, löst eine InvalidRequestError aus. Diese Strategie kann verwendet werden, wenn Objekte von ihrer angehängten Session getrennt werden sollen, nachdem sie geladen wurden.
- raise_on_sql - träges Laden, das SQL ausgibt, ist nicht erlaubt; der Zugriff auf das Attribut, wenn sein Wert nicht bereits durch Eager-Ladung geladen wurde, löst eine InvalidRequestError aus, **wenn das träge Laden SQL ausgeben muss**. Wenn das träge Laden den verwandten Wert aus der Identitätskarte abrufen oder feststellen kann, dass er None sein soll, wird der Wert geladen. Diese Strategie kann verwendet werden, wenn Objekte mit der angehängten Session verbunden bleiben, jedoch zusätzliche SELECT-Anweisungen blockiert werden sollen.
- write_only - das Attribut wird mit einer speziellen "virtuellen Sammlung" konfiguriert, die WriteOnlyCollection.add() und WriteOnlyCollection.remove()-Befehle empfangen kann, um einzelne Objekte hinzuzufügen oder zu entfernen, aber unter keinen Umständen die gesamte Sammlung direkt aus der Datenbank lädt oder durchläuft. Stattdessen werden Methoden wie WriteOnlyCollection.select(), WriteOnlyCollection.insert(), WriteOnlyCollection.update() und WriteOnlyCollection.delete() bereitgestellt, die SQL-Konstrukte erzeugen, die zum Laden und Ändern von Zeilen in großen Mengen verwendet werden können. Wird für große Sammlungen verwendet, die niemals sinnvoll in den Speicher geladen werden sollten.
  
  Der Laderstil write_only wird automatisch konfiguriert, wenn die WriteOnlyMapped-Annotation auf der linken Seite in einem Deklarativen Mapping angegeben ist. Siehe den Abschnitt Write-Only-Beziehungen für Beispiele.
  
  Neu in Version 2.0.
  
  Siehe auch
  
  Write-Only-Beziehungen - im ORM Querying Guide
- dynamic - das Attribut gibt ein voreingestelltes Query-Objekt für alle Leseoperationen zurück, auf das weitere Filteroperationen angewendet werden können, bevor die Ergebnisse durchlaufen werden.
  
  Der Laderstil dynamic wird automatisch konfiguriert, wenn die DynamicMapped-Annotation auf der linken Seite in einem Deklarativen Mapping angegeben ist. Siehe den Abschnitt Dynamische Beziehungs-Lader für Beispiele.
  
  Legacy-Funktion
  
  Die "dynamische" Lazy-Loading-Strategie ist die Legacy-Form der jetzigen "write_only"-Strategie, die im Abschnitt Write-Only-Beziehungen beschrieben wird.
  
  Siehe auch
  
  Dynamische Beziehungs-Lader - im ORM Querying Guide
  
  Write-Only-Beziehungen - allgemeiner nützlicherer Ansatz für große Sammlungen, die nicht vollständig in den Speicher geladen werden sollen
- True - ein Synonym für 'select'
- False - ein Synonym für 'joined'
- None - ein Synonym für 'noload'
Siehe auch

Relationship Loading Techniques - Vollständige Dokumentation zur Konfiguration von Beziehungs-Ladern im ORM Querying Guide.
load_on_pending=False¶ –
Gibt das Ladeverhalten für transiente oder ausstehende Elternobjekte an.

Wenn auf True gesetzt, veranlasst dies den Lazy-Loader, eine Abfrage für ein Elternobjekt auszugeben, das nicht persistent ist, d. h. nie geflusht wurde. Dies kann für ein ausstehendes Objekt wirksam werden, wenn Autoflush deaktiviert ist, oder für ein transientes Objekt, das an eine Session "angehängt" wurde, aber nicht Teil ihrer ausstehenden Sammlung ist.

Das Flag relationship.load_on_pending verbessert das Verhalten nicht, wenn die ORM normal verwendet wird - Objektverweise sollten auf Objektebene und nicht auf Fremdschlüsselebene erstellt werden, sodass sie vor einem Flush auf gewöhnliche Weise vorhanden sind. Dieses Flag ist nicht für den allgemeinen Gebrauch bestimmt.

Siehe auch

Session.enable_relationship_loading() - diese Methode etabliert das "Laden auf ausstehende"-Verhalten für das gesamte Objekt und ermöglicht auch das Laden von Objekten, die transient oder abgelöst bleiben.
order_by¶ –
Gibt die Reihenfolge an, die beim Laden dieser Elemente angewendet werden soll. relationship.order_by soll sich auf eines der Column-Objekte beziehen, auf die die Zielklasse abgebildet ist, oder auf das Attribut selbst, das an die Zielklasse gebunden ist und auf die Spalte verweist.

relationship.order_by kann auch als aufrufbare Funktion übergeben werden, die zur Initialisierungszeit des Mappers ausgewertet wird, und kann als Python-auswertbarer String übergeben werden, wenn Declarative verwendet wird.

Warnung

Wenn als Python-auswertbarer String übergeben, wird das Argument mithilfe der eval()-Funktion von Python interpretiert. **GEBEN SIE KEINE UNVERTRAUTEN EINGABEN AN DIESEN STRING WEITER**. Siehe Auswertung von Beziehungsargumenten für Details zur deklarativen Auswertung von relationship()-Argumenten.
passive_deletes=False¶ –
Gibt das Ladeverhalten während Löschvorgängen an.

Ein Wert von True bedeutet, dass nicht geladene Kindelemente bei einem Löschvorgang des Elternteils nicht geladen werden sollen. Normalerweise, wenn ein Elternteil gelöscht wird, werden alle Kindelemente geladen, damit sie entweder als gelöscht markiert oder ihr Fremdschlüssel zum Elternteil auf NULL gesetzt werden können. Das Setzen dieses Flags auf True impliziert normalerweise eine ON DELETE <<CASCADE|SET NULL>-Regel, die die Aktualisierung/Löschung von Kindzeilen auf Datenbankseite übernimmt.

Zusätzlich deaktiviert das Setzen des Flags auf den Zeichenkettenwert 'all' das "Nullsetzen" der Kind-Fremdschlüssel, wenn das Elternobjekt gelöscht wird und keine Delete- oder Delete-Orphan-Kaskade aktiviert ist. Dies wird typischerweise verwendet, wenn eine Trigger- oder Fehleraufruf-Situation auf Datenbankseite vorhanden ist. Beachten Sie, dass die Fremdschlüsselattribute bei Kindobjekten in der Sitzung nach einem Flush nicht geändert werden, daher ist dies eine sehr spezielle Verwendung. Außerdem erfolgt das "Nullsetzen" weiterhin, wenn das Kindobjekt vom Elternteil getrennt wird.

Siehe auch

Verwendung von ON DELETE-Fremdschlüsselkaskaden mit ORM-Beziehungen - Einführung in Dokumentation und Beispiele.
passive_updates=True¶ –
Gibt das Persistenzverhalten an, das angewendet werden soll, wenn sich ein referenzierter Primärschlüsselwert ändert, was bedeutet, dass die referenzierenden Fremdschlüsselspalten ebenfalls ihren Wert ändern müssen.

Wenn True, wird angenommen, dass ON UPDATE CASCADE auf dem Fremdschlüssel in der Datenbank konfiguriert ist und die Datenbank die Weitergabe eines UPDATES von einer Quellspalte an abhängige Zeilen übernimmt. Wenn False, versucht das SQLAlchemy relationship()-Konstrukt, eigene UPDATE-Anweisungen auszugeben, um verwandte Ziele zu ändern. Beachten Sie jedoch, dass SQLAlchemy **nicht** mehr als eine Kaskaden-Ebene aktualisieren kann. Außerdem ist das Setzen dieses Flags auf False nicht kompatibel, wenn die Datenbank tatsächlich die referentielle Integrität erzwingt, es sei denn, diese Einschränkungen sind ausdrücklich "aufgeschoben", wenn das Ziel-Backend dies unterstützt.

Es wird dringend empfohlen, dass eine Anwendung, die veränderliche Primärschlüssel verwendet, passive_updates auf True belässt und stattdessen die referentiellen Integritätsfunktionen der Datenbank selbst verwendet, um die Änderung effizient und vollständig zu handhaben.

Siehe auch

Veränderliche Primärschlüssel / Update-Kaskaden - Einführung in Dokumentation und Beispiele.

mapper.passive_updates - ein ähnliches Flag, das für Joined-Table-Inheritance-Mappings wirksam wird.
post_update¶ –
Dies zeigt an, dass die Beziehung nach einem INSERT oder vor einem DELETE mit einer zweiten UPDATE-Anweisung behandelt werden soll. Dieses Flag wird verwendet, um bidirektionale Abhängigkeiten zwischen zwei einzelnen Zeilen zu speichern (d. h. jede Zeile verweist auf die andere), bei denen es sonst unmöglich wäre, beide Zeilen vollständig einzufügen oder zu löschen, da eine Zeile vor der anderen existiert. Verwenden Sie dieses Flag, wenn eine bestimmte Mapping-Anordnung zwei voneinander abhängige Zeilen verursacht, wie z. B. eine Tabelle, die eine Eins-zu-Viele-Beziehung zu einer Reihe von Kindzeilen hat und auch eine Spalte enthält, die auf eine einzelne Kindzeile innerhalb dieser Liste verweist (d. h. beide Tabellen enthalten einen Fremdschlüssel füreinander). Wenn ein Flush-Vorgang einen Fehler zurückgibt, dass eine "zyklische Abhängigkeit" erkannt wurde, ist dies ein Hinweis darauf, dass Sie möglicherweise relationship.post_update verwenden möchten, um den Zyklus zu "brechen".

Siehe auch

Zeilen, die auf sich selbst zeigen / Gegenseitig abhängige Zeilen - Einführung in Dokumentation und Beispiele.
primaryjoin¶ –
Ein SQL-Ausdruck, der als primärer Join des Kindobjekts gegen das Elternobjekt oder bei einer Many-to-Many-Beziehung der Join des Elternobjekts mit der Assoziationstabelle verwendet wird. Standardmäßig wird dieser Wert basierend auf den Fremdschlüsselbeziehungen der Eltern- und Kindtabellen (oder der Assoziationstabelle) berechnet.

relationship.primaryjoin kann auch als aufrufbare Funktion übergeben werden, die zur Initialisierungszeit des Mappers ausgewertet wird, und kann als Python-auswertbarer String übergeben werden, wenn Declarative verwendet wird.

Warnung

Wenn als Python-auswertbarer String übergeben, wird das Argument mithilfe der eval()-Funktion von Python interpretiert. **GEBEN SIE KEINE UNVERTRAUTEN EINGABEN AN DIESEN STRING WEITER**. Siehe Auswertung von Beziehungsargumenten für Details zur deklarativen Auswertung von relationship()-Argumenten.

Siehe auch

Angabe alternativer Verknüpfungsbedingungen
remote_side¶ –
Wird für selbst referenzierende Beziehungen verwendet und gibt die Spalte oder Liste von Spalten an, die die "entfernte Seite" der Beziehung bilden.

relationship.remote_side kann auch als aufrufbare Funktion übergeben werden, die zur Initialisierungszeit des Mappers ausgewertet wird, und kann als Python-auswertbarer String übergeben werden, wenn Declarative verwendet wird.

Warnung

Wenn als Python-auswertbarer String übergeben, wird das Argument mithilfe der eval()-Funktion von Python interpretiert. **GEBEN SIE KEINE UNVERTRAUTEN EINGABEN AN DIESEN STRING WEITER**. Siehe Auswertung von Beziehungsargumenten für Details zur deklarativen Auswertung von relationship()-Argumenten.

Siehe auch

Adjazenzlisten-Beziehungen - eingehende Erklärung, wie relationship.remote_side zur Konfiguration selbst referenzierender Beziehungen verwendet wird.

remote() - eine Annotationsfunktion, die denselben Zweck erfüllt wie relationship.remote_side, typischerweise wenn eine benutzerdefinierte relationship.primaryjoin-Bedingung verwendet wird.
query_class¶ –
Eine Query-Unterklasse, die intern von der AppenderQuery verwendet wird, die von einer "dynamischen" Beziehung zurückgegeben wird, d. h. einer Beziehung, die lazy="dynamic" angibt oder anderweitig mit der Funktion dynamic_loader() erstellt wurde.

Siehe auch

Dynamische Beziehungs-Lader - Einführung in "dynamische" Beziehungs-Lader.
secondaryjoin¶ –
Ein SQL-Ausdruck, der als Join einer Assoziationstabelle mit dem Kindobjekt verwendet wird. Standardmäßig wird dieser Wert basierend auf den Fremdschlüsselbeziehungen der Assoziations- und Kindtabellen berechnet.

relationship.secondaryjoin kann auch als aufrufbare Funktion übergeben werden, die zur Initialisierungszeit des Mappers ausgewertet wird, und kann als Python-auswertbarer String übergeben werden, wenn Declarative verwendet wird.

Warnung

Wenn als Python-auswertbarer String übergeben, wird das Argument mithilfe der eval()-Funktion von Python interpretiert. **GEBEN SIE KEINE UNVERTRAUTEN EINGABEN AN DIESEN STRING WEITER**. Siehe Auswertung von Beziehungsargumenten für Details zur deklarativen Auswertung von relationship()-Argumenten.

Siehe auch

Angabe alternativer Verknüpfungsbedingungen
single_parent¶ –
Wenn True, installiert einen Validator, der verhindert, dass Objekte gleichzeitig mit mehr als einem Elternteil assoziiert werden. Dies wird für Many-to-One- oder Many-to-Many-Beziehungen verwendet, die entweder als One-to-One oder One-to-Many behandelt werden sollen. Die Verwendung ist optional, außer für relationship()-Konstrukte, die Many-to-One oder Many-to-Many sind und außerdem die Kaskadenoption delete-orphan angeben. Das relationship()-Konstrukt selbst löst eine Fehlermeldung aus, die angibt, wann diese Option erforderlich ist.

Siehe auch

Kaskaden - enthält Details dazu, wann das Flag relationship.single_parent geeignet sein kann.
uselist¶ –
Ein Boolescher Wert, der angibt, ob diese Eigenschaft als Liste oder Skalar geladen werden soll. In den meisten Fällen wird dieser Wert automatisch von relationship() zur Mapper-Konfigurationszeit bestimmt. Bei der Verwendung von expliziten Mapped-Annotationen kann relationship.uselist davon abgeleitet werden, ob die Annotation innerhalb von Mapped eine Sammlungsklasse enthält. Andernfalls kann relationship.uselist vom Typ und der Richtung der Beziehung abgeleitet werden - Eins-zu-Viele bildet eine Liste, Viele-zu-Eins bildet einen Skalar, Viele-zu-Viele ist eine Liste. Wenn ein Skalar gewünscht wird, wo normalerweise eine Liste vorhanden wäre, wie z. B. bei einer bidirektionalen Eins-zu-Eins-Beziehung, verwenden Sie eine geeignete Mapped-Annotation oder setzen Sie relationship.uselist auf False.

Das Flag relationship.uselist ist auch als schreibgeschütztes Attribut für ein bestehendes relationship()-Konstrukt verfügbar, das verwendet werden kann, um festzustellen, ob dieses relationship() mit Sammlungen oder Skalarattributen umgeht.
```
>>> User.addresses.property.uselist
True
```
Siehe auch

Eins zu Eins - Einführung in das "Eins-zu-Eins"-Beziehungsmuster, bei dem normalerweise eine alternative Einstellung für relationship.uselist verwendet wird.
viewonly=False¶ –
Wenn auf True gesetzt, wird die Beziehung nur zum Laden von Objekten verwendet, nicht für Operationen zur Persistenz. Eine relationship(), die relationship.viewonly spezifiziert, kann mit einer breiteren Palette von SQL-Operationen innerhalb der relationship.primaryjoin Bedingung arbeiten, einschließlich Operationen, die die Verwendung verschiedener Vergleichsoperatoren sowie SQL-Funktionen wie cast() beinhalten. Das Flag relationship.viewonly ist auch generell nützlich, wenn jede Art von relationship() definiert wird, die nicht die vollständige Menge verwandter Objekte darstellt, um zu verhindern, dass Änderungen an der Sammlung zu Persistenzoperationen führen.

Siehe auch

Hinweise zur Verwendung des viewonly-Beziehungsparameters - weitere Details zu Best Practices bei der Verwendung von relationship.viewonly.
sync_backref¶ –
Ein boolescher Wert, der die Ereignisse aktiviert, die zum Synchronisieren der In-Python-Attribute verwendet werden, wenn diese Beziehung Ziel von entweder relationship.backref oder relationship.back_populates ist.

Standardmäßig None, was darauf hinweist, dass ein automatischer Wert basierend auf dem Wert des Flags relationship.viewonly ausgewählt werden soll. Wenn dies auf seinem Standardwert belassen wird, werden Zustandsänderungen nur dann zurückpropagiert, wenn keine Seite einer Beziehung viewonly ist.

Neu in Version 1.3.17.

Geändert in Version 1.4: - Eine Beziehung, die relationship.viewonly spezifiziert, impliziert automatisch, dass relationship.sync_backref False ist.

Siehe auch

relationship.viewonly
omit_join¶ –
Ermöglicht manuelle Kontrolle über die automatische Join-Optimierung für „selectin“. Auf False gesetzt, um die in SQLAlchemy 1.3 hinzugefügte „omit join“-Funktion zu deaktivieren; oder auf None belassen, um die automatische Optimierung beizubehalten.

Hinweis

Dieses Flag kann nur auf False gesetzt werden. Es ist nicht notwendig, es auf True zu setzen, da die „omit_join“-Optimierung automatisch erkannt wird; wenn sie nicht erkannt wird, wird die Optimierung nicht unterstützt.

Geändert in Version 1.3.11: das Setzen von omit_join auf True gibt nun eine Warnung aus, da dies nicht der vorgesehene Verwendungszweck dieses Flags war.

Neu in Version 1.3.
init¶ – Spezifisch für Declarative Dataclass Mapping, gibt an, ob das gemappte Attribut Teil der von dem Dataclass-Prozess generierten __init__() Methode sein soll.
repr¶ – Spezifisch für Declarative Dataclass Mapping, gibt an, ob das gemappte Attribut Teil der von dem Dataclass-Prozess generierten __repr__() Methode sein soll.
default_factory¶ – Spezifisch für Declarative Dataclass Mapping, gibt eine Funktion zur Erzeugung von Standardwerten an, die als Teil der von dem Dataclass-Prozess generierten __init__() Methode ausgeführt wird.
compare¶ –
Spezifisch für Deklaratives Mapping von Datenklassen, gibt an, ob dieses Feld bei der Generierung der Methoden __eq__() und __ne__() für die zugeordnete Klasse in Vergleichsoperationen einbezogen werden soll.

Neu ab Version 2.0.0b4.
kw_only¶ – Spezifisch für Declarative Dataclass Mapping, gibt an, ob dieses Feld beim Generieren der __init__() als nur-Schlüsselwort-Argument gekennzeichnet werden soll.
hash¶ –
Spezifisch für Deklaratives Mapping von Datenklassen, steuert, ob dieses Feld bei der Generierung der __hash__()-Methode für die zugeordnete Klasse einbezogen wird.

Neu in Version 2.0.36.

function sqlalchemy.orm.backref(name: str, **kwargs: Any) → ORMBackrefArgument¶

Wenn der Parameter relationship.backref verwendet wird, werden spezifische Parameter bereitgestellt, die bei der Generierung der neuen relationship() verwendet werden.

Z. B.

"items": relationship(SomeItem, backref=backref("parent", lazy="subquery"))

Der Parameter relationship.backref gilt im Allgemeinen als veraltet; für moderne Anwendungen sollten explizite relationship() Konstrukte bevorzugt werden, die über den Parameter relationship.back_populates miteinander verbunden sind.

Siehe auch

Verwendung des veralteten ‘backref’ Beziehungsparameters - Hintergrund zu Backrefs

function sqlalchemy.orm.dynamic_loader(argument: _RelationshipArgumentType[Any] | None = None, **kw: Any) → RelationshipProperty[Any]¶

Konstruiert eine dynamisch ladende Mapper-Eigenschaft.

Dies ist im Wesentlichen dasselbe wie die Verwendung des Arguments lazy='dynamic' mit relationship()

dynamic_loader(SomeClass)

# is the same as

relationship(SomeClass, lazy="dynamic")

Weitere Details zu dynamischem Laden finden Sie im Abschnitt Dynamic Relationship Loaders.

function sqlalchemy.orm.foreign(expr: _CEA) → _CEA¶

Annotiert einen Teil eines Primaryjoin-Ausdrucks mit einer ‚foreign‘-Annotation.

Siehe den Abschnitt Erstellung benutzerdefinierter Fremdschlüsselbedingungen für eine Beschreibung der Verwendung.

Siehe auch

Erstellung benutzerdefinierter Fremdschlüsselbedingungen

remote()

function sqlalchemy.orm.remote(expr: _CEA) → _CEA¶

Annotiert einen Teil eines Primaryjoin-Ausdrucks mit einer ‚remote‘-Annotation.

Siehe den Abschnitt Erstellung benutzerdefinierter Fremdschlüsselbedingungen für eine Beschreibung der Verwendung.

Siehe auch

Erstellung benutzerdefinierter Fremdschlüsselbedingungen

foreign()

SQLAlchemy 2.0 Dokumentation

SQLAlchemy 2.0 Dokumentation

SQLAlchemy ORM

Projektversionen

Relationships API¶