]> 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:23 +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 ccda5f20b20715072b207dd7ee77e3e3d0921e7c..0dd1a28c35f60c60be4852a6a9382c8804c8f1c5 100644 (file)
@@ -628,14 +628,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``