From: Doctor <thirvondukr@gmail.com>
Date: Mon, 25 Apr 2022 01:29:10 +0000 (+0300)
Subject: format cascades.rst
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=aa5a1fe30bf17c1700a9b217c73dfcc030b090ea;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git

format cascades.rst
---

diff --git a/doc/build/orm/cascades.rst b/doc/build/orm/cascades.rst
index c9e16cbaca..576c856d53 100644
--- a/doc/build/orm/cascades.rst
+++ b/doc/build/orm/cascades.rst
@@ -32,11 +32,11 @@ To set cascades on a backref, the same flag can be used with the
 its arguments back into :func:`~sqlalchemy.orm.relationship`::
 
     class Item(Base):
-        __tablename__ = 'item'
+        __tablename__ = "item"
 
-        order = relationship("Order",
-                        backref=backref("items", cascade="all, delete-orphan")
-                    )
+        order = relationship(
+            "Order", backref=backref("items", cascade="all, delete-orphan")
+        )
 
 .. sidebar:: The Origins of Cascade
 
@@ -147,13 +147,17 @@ To illustrate, given a mapping of ``Order`` objects which relate
 bi-directionally to a series of ``Item`` objects via relationships
 ``Order.items`` and ``Item.order``::
 
-    mapper_registry.map_imperatively(Order, order_table, properties={
-        'items' : relationship(Item, back_populates='order')
-    })
+    mapper_registry.map_imperatively(
+        Order,
+        order_table,
+        properties={"items": relationship(Item, back_populates="order")},
+    )
 
-    mapper_registry.map_imperatively(Item, item_table, properties={
-        'order' : relationship(Order, back_populates='items')
-    })
+    mapper_registry.map_imperatively(
+        Item,
+        item_table,
+        properties={"order": relationship(Order, back_populates="items")},
+    )
 
 If an ``Order`` is already associated with a :class:`_orm.Session`, and
 an ``Item`` object is then created and appended to the ``Order.items``
@@ -319,23 +323,27 @@ The following example adapts that of :ref:`relationships_many_to_many` to
 illustrate the ``cascade="all, delete"`` setting on **one** side of the
 association::
 
-    association_table = Table('association', Base.metadata,
-        Column('left_id', Integer, ForeignKey('left.id')),
-        Column('right_id', Integer, ForeignKey('right.id'))
+    association_table = Table(
+        "association",
+        Base.metadata,
+        Column("left_id", Integer, ForeignKey("left.id")),
+        Column("right_id", Integer, ForeignKey("right.id")),
     )
 
+
     class Parent(Base):
-        __tablename__ = 'left'
+        __tablename__ = "left"
         id = Column(Integer, primary_key=True)
         children = relationship(
             "Child",
             secondary=association_table,
             back_populates="parents",
-            cascade="all, delete"
+            cascade="all, delete",
         )
 
+
     class Child(Base):
-        __tablename__ = 'right'
+        __tablename__ = "right"
         id = Column(Integer, primary_key=True)
         parents = relationship(
             "Parent",
@@ -398,18 +406,20 @@ on the relevant ``FOREIGN KEY`` constraint as well::
 
 
     class Parent(Base):
-        __tablename__ = 'parent'
+        __tablename__ = "parent"
         id = Column(Integer, primary_key=True)
         children = relationship(
-            "Child", back_populates="parent",
+            "Child",
+            back_populates="parent",
             cascade="all, delete",
-            passive_deletes=True
+            passive_deletes=True,
         )
 
+
     class Child(Base):
-        __tablename__ = 'child'
+        __tablename__ = "child"
         id = Column(Integer, primary_key=True)
-        parent_id = Column(Integer, ForeignKey('parent.id', ondelete="CASCADE"))
+        parent_id = Column(Integer, ForeignKey("parent.id", ondelete="CASCADE"))
         parent = relationship("Parent", back_populates="children")
 
 The behavior of the above configuration when a parent row is deleted
@@ -548,13 +558,16 @@ on the parent->child side of the relationship, and we can then configure
 ``passive_deletes=True`` on the **other** side of the bidirectional
 relationship as illustrated below::
 
-    association_table = Table('association', Base.metadata,
-        Column('left_id', Integer, ForeignKey('left.id', ondelete="CASCADE")),
-        Column('right_id', Integer, ForeignKey('right.id', ondelete="CASCADE"))
+    association_table = Table(
+        "association",
+        Base.metadata,
+        Column("left_id", Integer, ForeignKey("left.id", ondelete="CASCADE")),
+        Column("right_id", Integer, ForeignKey("right.id", ondelete="CASCADE")),
     )
 
+
     class Parent(Base):
-        __tablename__ = 'left'
+        __tablename__ = "left"
         id = Column(Integer, primary_key=True)
         children = relationship(
             "Child",
@@ -563,14 +576,15 @@ relationship as illustrated below::
             cascade="all, delete",
         )
 
+
     class Child(Base):
-        __tablename__ = 'right'
+        __tablename__ = "right"
         id = Column(Integer, primary_key=True)
         parents = relationship(
             "Parent",
             secondary=association_table,
             back_populates="children",
-            passive_deletes=True
+            passive_deletes=True,
         )
 
 Using the above configuration, the deletion of a ``Parent`` object proceeds
@@ -712,12 +726,11 @@ parent collection.  The ``delete-orphan`` cascade accomplishes this, as
 illustrated in the example below::
 
     class User(Base):
-        __tablename__ = 'user'
+        __tablename__ = "user"
 
         # ...
 
-        addresses = relationship(
-            "Address", cascade="all, delete-orphan")
+        addresses = relationship("Address", cascade="all, delete-orphan")
 
     # ...
 
@@ -739,9 +752,8 @@ that this related object is not to shared with any other parent simultaneously::
         # ...
 
         preference = relationship(
-            "Preference", cascade="all, delete-orphan",
-            single_parent=True)
-
+            "Preference", cascade="all, delete-orphan", single_parent=True
+        )
 
 Above, if a hypothetical ``Preference`` object is removed from a ``User``,
 it will be deleted on flush::