clarify eager loading terminology

Change-Id: Idb27ec5f09ef958d71738e1095b4be7a1377eecb
(cherry picked from commit 4b5ed6ad27b3b63ecf1b082653e2e3ee0abb887f)

diff --git a/doc/build/orm/queryguide.rst b/doc/build/orm/queryguide.rst
index 06d3dace9031a46bab69725a45b10f563adff26c..747a70abbf906c26bca514125eca80fe6eca3aeb 100644 (file)
--- a/doc/build/orm/queryguide.rst
+++ b/doc/build/orm/queryguide.rst
@@ -1078,10 +1078,12 @@ When ``yield_per`` is used, the
 set for the Core execution, so that a streaming / server side cursor will be
 used if the backend supports it.
 
-The ``yield_per`` execution option **is not compatible with subqueryload eager
-loading or joinedload eager loading when using collections**.  It is
-potentially compatible with selectinload eager loading, provided the database
-driver supports multiple, independent cursors.
+The ``yield_per`` execution option **is not compatible** with
+:ref:`"subquery" eager loading <subquery_eager_loading>` loading or
+:ref:`"joined" eager loading <joined_eager_loading>` when using collections. It
+is potentially compatible with :ref:`"select in" eager loading
+<selectin_eager_loading>` , provided the database driver supports multiple,
+independent cursors.
 
 Additionally, the ``yield_per`` execution option is not compatible
 with the :meth:`_engine.Result.unique` method; as this method relies upon