]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commitdiff
Clarify LegacyRow / Row verbiage
authorMike Bayer <mike_mp@zzzcomputing.com>
Mon, 15 Mar 2021 23:34:49 +0000 (19:34 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Mon, 15 Mar 2021 23:34:49 +0000 (19:34 -0400)
Change-Id: I40db17216f09757ff49e87297ff9dd8aae18ed97
References: #6051

doc/build/changelog/migration_20.rst

index 1a056803ace8821231cb5b0617819276cf7c9305..b9b36976db46b9aa595d09df88e3e644b0381b44 100644 (file)
@@ -844,9 +844,12 @@ used by code that already knows what columns are present within it.
 Already part of 1.4, the previous ``KeyedTuple`` class that was used when
 selecting rows from the :class:`_query.Query` object has been replaced by the
 :class:`.Row` class, which is the base of the same :class:`.Row` that comes
-back with Core statement results (in 1.4 when not using the
-:paramref:`_sa.create_engine.future` flag with an :class:`_engine.Engine`,
-it is the :class:`.LegacyRow` class).
+back with Core statement results when using the
+:paramref:`_sa.create_engine.future` flag with :class:`_engine.Engine` (when
+the :paramref:`_sa.create_engine.future` flag is not set, Core result sets use
+the :class:`.LegacyRow` subclass, which maintains backwards-compatible
+behaviors for the ``__contains__()`` method; ORM exclusively uses the
+:class:`.Row` class directly).
 
 This :class:`.Row` behaves like a named tuple, in that it acts as a sequence
 but also supports attribute name access, e.g. ``row.some_column``.  However,