Link to the ExpireRelationshipOnFKChange recipe for deletes

The recipe now supports interception of delete() and a
corresponding update of related objects.

Change-Id: I2aa3bfdd477ceccff6cfb3e66ed73311705010c7

diff --git a/doc/build/orm/session_basics.rst b/doc/build/orm/session_basics.rst
index 010c210acd99981e47b84d1edca056d949405431..6f3500abbbde2b881336c2e9cac00e623d5fc43c 100644 (file)
--- a/doc/build/orm/session_basics.rst
+++ b/doc/build/orm/session_basics.rst
@@ -618,11 +618,13 @@ desired state::
     >>> address in user.addresses
     False
 
-The usual practice of deleting items within collections is to forego the usage
-of :meth:`~.Session.delete` directly, and instead use cascade behavior to
-automatically invoke the deletion as a result of removing the object from
-the parent collection.  The ``delete-orphan`` cascade accomplishes this,
-as illustrated in the example below::
+There is a recipe for intercepting :meth:`.Session.delete` and invoking this
+expiration automatically; see `ExpireRelationshipOnFKChange <http://www.sqlalchemy.org/trac/wiki/UsageRecipes/ExpireRelationshipOnFKChange>`_ for this.  However, the usual practice of
+deleting items within collections is to forego the usage of
+:meth:`~.Session.delete` directly, and instead use cascade behavior to
+automatically invoke the deletion as a result of removing the object from the
+parent collection.  The ``delete-orphan`` cascade accomplishes this, as
+illustrated in the example below::
 
     class User(Base):
         __tablename__ = 'user'
@@ -664,6 +666,7 @@ it will be deleted on flush::
 
 See also :ref:`unitofwork_cascades` for detail on cascades.
 
+
 Deleting based on Filter Criterion
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~