]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commitdiff
remove nonsensical note
authorMike Bayer <mike_mp@zzzcomputing.com>
Thu, 18 Aug 2022 15:29:25 +0000 (11:29 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Thu, 18 Aug 2022 15:30:09 +0000 (11:30 -0400)
this note is not factually incorrect but it makes no sense
why this would be in the middle of the abstract concrete doc

Change-Id: Icd67d9d9a93ee72714bf85d8d5ca39c0af61f356
(cherry picked from commit acf14885833da238606e6a0df7c5ab256e477f2c)

doc/build/orm/inheritance.rst

index e9b1998ee5b1b1ae77a256d0286444ba6ad7cbdd..27498b375aff6469e51d5452e21b17774b945346 100644 (file)
@@ -770,14 +770,6 @@ of ``Manager`` and ``Engineer`` instances.    This brings us back into the
 domain of concrete inheritance, and we must build a special mapper against
 ``Employee`` in order to achieve this.
 
-.. topic:: Mappers can always SELECT
-
-    In SQLAlchemy, a mapper for a class always has to refer to some
-    "selectable", which is normally a :class:`_schema.Table` but may also refer to any
-    :func:`_expression.select` object as well.   While it may appear that a "single table
-    inheritance" mapper does not map to a table, these mappers in fact
-    implicitly refer to the table that is mapped by a superclass.
-
 To modify our concrete inheritance example to illustrate an "abstract" base
 that is capable of polymorphic loading,
 we will have only an ``engineer`` and a ``manager`` table and no ``employee``