SqlAlchemy 2.0 中文文档(三十九)(1)

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: SqlAlchemy 2.0 中文文档(三十九)


原文:docs.sqlalchemy.org/en/20/contents.html

反射数据库对象

原文:docs.sqlalchemy.org/en/20/core/reflection.html

可以命令Table对象从数据库中已经存在的相应数据库架构对象中加载关于自身的信息。这个过程称为反射。在最简单的情况下,您只需要指定表名、一个MetaData对象和autoload_with参数:

>>> messages = Table("messages", metadata_obj, autoload_with=engine)
>>> [c.name for c in messages.columns]
['message_id', 'message_name', 'date']

上述操作将使用给定的引擎来查询有关messages表格的数据库信息,然后将生成ColumnForeignKey和其他对象,这些对象对应于此信息,就像Table对象在 Python 中手工构造一样。

当表格被反射时,如果给定的表格通过外键引用另一个表格,那么在表示连接的MetaData对象中将创建第二个 Table对象。下面假设表格shopping_cart_items引用了一个名为shopping_carts的表格。反射shopping_cart_items表格的效果是shopping_carts表格也将被加载:

>>> shopping_cart_items = Table("shopping_cart_items", metadata_obj, autoload_with=engine)
>>> "shopping_carts" in metadata_obj.tables
True

MetaData具有一种有趣的“类单例”行为,即如果您单独请求了两个表格,MetaData将确保为每个不同的表名创建一个 Table对象。如果具有给定名称的表格已经存在,则Table构造函数实际上会将已经存在的Table对象返回给您。例如,我们可以通过以下方式访问已经生成的shopping_carts表格:

shopping_carts = Table("shopping_carts", metadata_obj)

当然,无论如何,最好在上述表格中使用autoload_with=engine。这样,如果尚未加载表格的属性,它们将被加载。只有在尚未加载表格的情况下才会自动加载表格;一旦加载,对于具有相同名称的新调用Table将不会重新发出任何反射查询。

覆盖反射的列

当反映表格时,可以通过显式值覆盖单个列;这对于指定自定义数据类型、数据库中可能未配置的主键等约束非常方便:

>>> mytable = Table(
...     "mytable",
...     metadata_obj,
...     Column(
...         "id", Integer, primary_key=True
...     ),  # override reflected 'id' to have primary key
...     Column("mydata", Unicode(50)),  # override reflected 'mydata' to be Unicode
...     # additional Column objects which require no change are reflected normally
...     autoload_with=some_engine,
... )

另请参阅

使用自定义类型和反射 - 说明了上述列覆盖技术如何应用于使用自定义数据类型进行表反射。

反射视图

反射系统也可以反射视图。基本用法与表的用法相同:

my_view = Table("some_view", metadata, autoload_with=engine)

在上面,my_view 是一个具有 Column 对象的 Table 对象,表示视图“some_view”中每列的名称和类型。

通常,在反映视图时,至少希望有一个主键约束,如果可能的话,也有外键。视图反射不会推断这些约束。

使用“覆盖”技术,明确指定那些是主键的列或具有外键约束的列:

my_view = Table(
    "some_view",
    metadata,
    Column("view_id", Integer, primary_key=True),
    Column("related_thing", Integer, ForeignKey("othertable.thing_id")),
    autoload_with=engine,
)

一次性反射所有表格

MetaData 对象还可以获取表的列表并反映全部。这通过使用 reflect() 方法实现。调用后,所有定位的表格都存在于 MetaData 对象的表字典中:

metadata_obj = MetaData()
metadata_obj.reflect(bind=someengine)
users_table = metadata_obj.tables["users"]
addresses_table = metadata_obj.tables["addresses"]

metadata.reflect() 还提供了一种方便的方式来清除或删除数据库中的所有行:

metadata_obj = MetaData()
metadata_obj.reflect(bind=someengine)
with someengine.begin() as conn:
    for table in reversed(metadata_obj.sorted_tables):
        conn.execute(table.delete())

从其他架构中反射表格

章节 指定架构名称 介绍了表架构的概念,这是数据库中包含表和其他对象的命名空间,可以明确指定。Table 对象的“架构”,以及视图、索引和序列等其他对象的“架构”,可以使用 Table.schema 参数进行设置,也可以使用 MetaData.schema 参数作为 MetaData 对象的默认架构。

此架构参数的使用直接影响表反射功能在被要求反射对象时的搜索位置。例如,给定通过其 MetaData.schema 参数配置了默认架构名称“project”的 MetaData 对象:

>>> metadata_obj = MetaData(schema="project")

然后,MetaData.reflect()将利用配置的.schema进行反射:

>>> # uses `schema` configured in metadata_obj
>>> metadata_obj.reflect(someengine)

最终结果是,来自“project”模式的Table对象将被反映出来,并且它们将以该名称作为模式限定进行填充:

>>> metadata_obj.tables["project.messages"]
Table('messages', MetaData(), Column('message_id', INTEGER(), table=<messages>), schema='project')

类似地,包括Table.schema参数的单个Table对象也将从该数据库模式反映出来,覆盖可能已经在拥有的MetaData集合上配置的任何默认模式:

>>> messages = Table("messages", metadata_obj, schema="project", autoload_with=someengine)
>>> messages
Table('messages', MetaData(), Column('message_id', INTEGER(), table=<messages>), schema='project')

最后,MetaData.reflect()方法本身也允许传递一个MetaData.reflect.schema参数,因此我们也可以为默认配置的MetaData对象从“project”模式加载表:

>>> metadata_obj = MetaData()
>>> metadata_obj.reflect(someengine, schema="project")

我们可以使用不同的MetaData.schema参数(或者完全不使用)任意多次调用MetaData.reflect(),以继续用更多对象填充MetaData对象:

>>> # add tables from the "customer" schema
>>> metadata_obj.reflect(someengine, schema="customer")
>>> # add tables from the default schema
>>> metadata_obj.reflect(someengine)

与默认模式交互的模式限定反射

最佳实践总结部分

在本节中,我们讨论了 SQLAlchemy 关于数据库会话中“默认模式”可见的表的反射行为,以及这些如何与明确包含模式的  SQLAlchemy 指令相互作用。作为最佳实践,请确保数据库的“默认”模式只是一个单一名称,而不是名称列表;对于属于此“默认”模式并且可以在  DDL 和 SQL 中不带模式限定命名的表,请将相应的Table.schema和类似的模式参数设置为它们的默认值None

如 在 MetaData 中指定默认模式名称  中所述,具有模式概念的数据库通常还包括“默认”模式的概念。这自然是因为当引用没有模式的表对象时(这是常见的情况),支持模式的数据库仍然会认为该表在某处存在“模式”。一些数据库,如  PostgreSQL,将这个概念进一步扩展为 模式搜索路径,在特定数据库会话中可以考虑多个模式名称为“隐式”;引用其中任何一个模式中的表名都不需要存在模式名称(与此同时,如果模式名称存在,则也是完全可以的)。

由于大多数关系型数据库都有特定的表对象概念,可以以模式限定的方式引用,也可以以“隐式”方式引用,即没有模式存在,这给 SQLAlchemy 的反射特性带来了复杂性。以模式限定方式反射表将始终填充其 Table.schema 属性,并且会影响此 Table 如何组织到 MetaData.tables 集合中,也就是以模式限定方式。相反,以非模式限定方式反射 同样的 表将使其以非模式限定方式组织到 MetaData.tables 集合中。最终的结果是,单个 MetaData 集合中将存在两个独立的表示实际数据库中同一表的 Table 对象。

为了说明这个问题的影响,考虑前面示例中“project”模式中的表,并假设“project”模式也是我们数据库连接的默认模式,或者如果使用 PostgreSQL 等数据库,则假设“project”模式设置在 PostgreSQL 的 search_path 中。这意味着数据库接受以下两个 SQL 语句作为等价:

-- schema qualified
SELECT  message_id  FROM  project.messages
-- non-schema qualified
SELECT  message_id  FROM  messages

在 SQLAlchemy 中,这并不是一个问题,因为可以以两种方式找到表。但是,在 SQLAlchemy 中,是Table对象的标识决定了它在 SQL 语句中的语义角色。基于 SQLAlchemy 当前的决策,这意味着如果我们以模式限定的方式和非模式限定的方式反射相同的“messages”表,我们将得到两个不会被视为语义等同的Table对象:

>>> # reflect in non-schema qualified fashion
>>> messages_table_1 = Table("messages", metadata_obj, autoload_with=someengine)
>>> # reflect in schema qualified fashion
>>> messages_table_2 = Table(
...     "messages", metadata_obj, schema="project", autoload_with=someengine
... )
>>> # two different objects
>>> messages_table_1 is messages_table_2
False
>>> # stored in two different ways
>>> metadata.tables["messages"] is messages_table_1
True
>>> metadata.tables["project.messages"] is messages_table_2
Tru

当被反映的表包含对其他表的外键引用时,上述问题变得更加复杂。假设“messages”有一个“project_id”列,它引用另一个模式本地表“projects”的行,这意味着“messages”表的定义中有一个ForeignKeyConstraint对象。

我们可能会发现自己处于一个情况下,其中一个MetaData集合可能包含表示这两个数据库表的四个Table对象,其中一个或两个附加表是由反射过程生成的;这是因为当反射过程遇到要反射的表上的外键约束时,它会分支出去反射该引用表。它用于为这个引用表分配模式的决策是,如果拥有的Table也省略了其模式名称,并且这两个对象位于相同的模式中,则 SQLAlchemy 将省略默认模式从反射的ForeignKeyConstraint对象中,但如果没有省略,则包括它。

常见的情况是以模式限定的方式反射表,然后以模式限定的方式加载一个相关表:

>>> # reflect "messages" in a schema qualified fashion
>>> messages_table_1 = Table(
...     "messages", metadata_obj, schema="project", autoload_with=someengine
... )

上述messages_table_1也将以模式限定的方式引用projects。这个projects表将自动反映出“messages”引用它的事实:

>>> messages_table_1.c.project_id
Column('project_id', INTEGER(), ForeignKey('project.projects.project_id'), table=<messages>)

如果代码的其他部分以非模式限定的方式反映“projects”,那么现在有两个不同的项目表:

>>> # reflect "projects" in a non-schema qualified fashion
>>> projects_table_1 = Table("projects", metadata_obj, autoload_with=someengine)
>>> # messages does not refer to projects_table_1 above
>>> messages_table_1.c.project_id.references(projects_table_1.c.project_id)
False
>>> # it refers to this one
>>> projects_table_2 = metadata_obj.tables["project.projects"]
>>> messages_table_1.c.project_id.references(projects_table_2.c.project_id)
True
>>> # they're different, as one non-schema qualified and the other one is
>>> projects_table_1 is projects_table_2
False

上述混淆可能会在使用表反射加载应用程序级Table对象的应用程序中以及在迁移场景中(尤其是使用 Alembic Migrations 检测新表和外键约束时)引起问题。

以上行为可以通过坚持一项简单的做法来纠正:

  • 对于期望位于数据库默认模式中的任何Table,不要包含Table.schema参数。

对于支持模式“搜索”路径的 PostgreSQL 和其他数据库,添加以下额外做法:

  • 将“搜索路径”限定为仅一个模式,即默认模式

另请参阅

远程模式表反射和 PostgreSQL 搜索路径 - 关于 PostgreSQL 数据库的此行为的附加细节。## 使用检查器进行精细化反射

还提供了一个低级接口,它提供了一种与后端无关的从给定数据库加载模式、表、列和约束描述列表的系统。这被称为“检查器”:

from sqlalchemy import create_engine
from sqlalchemy import inspect
engine = create_engine("...")
insp = inspect(engine)
print(insp.get_table_names())
对象名称 描述
Inspector 执行数据库模式检查。
ReflectedCheckConstraint 表示与CheckConstraint对应的反射元素的字典。
ReflectedColumn 表示与Column对象对应的反射元素的字典。
ReflectedComputed 表示计算列的反射元素,对应于Computed构造。
ReflectedForeignKeyConstraint 表示与ForeignKeyConstraint对应的反射元素的字典。
ReflectedIdentity 表示列的反射 IDENTITY 结构,对应于Identity构造。
ReflectedIndex 表示与Index对应的反射元素的字典。
ReflectedPrimaryKeyConstraint 表示与PrimaryKeyConstraint对应的反射元素的字典。
ReflectedTableComment 表示对应于Table.comment属性的反射注释的字典。
ReflectedUniqueConstraint 表示对应于UniqueConstraint的反射元素的字典。
class sqlalchemy.engine.reflection.Inspector

执行数据库模式检查。

Inspector 充当Dialect的反射方法的代理,提供一致的接口以及对先前获取的元数据的缓存支持。

Inspector 对象通常通过inspect()函数创建,该函数可以传递一个Engine或一个Connection

from sqlalchemy import inspect, create_engine
engine = create_engine('...')
insp = inspect(engine)

在上述情况中,与引擎关联的Dialect可能选择返回一个提供了特定于方言目标数据库的额外方法的Inspector子类。

成员

init(), bind, clear_cache(), default_schema_name,  dialect, engine, from_engine(), get_check_constraints(), get_columns(),  get_foreign_keys(), get_indexes(), get_materialized_view_names(),  get_multi_check_constraints(), get_multi_columns(),  get_multi_foreign_keys(), get_multi_indexes(),  get_multi_pk_constraint(), get_multi_table_comment(),  get_multi_table_options(), get_multi_unique_constraints(),  get_pk_constraint(), get_schema_names(), get_sequence_names(),  get_sorted_table_and_fkc_names(), get_table_comment(),  get_table_names(), get_table_options(), get_temp_table_names(),  get_temp_view_names(), get_unique_constraints(), get_view_definition(),  get_view_names(), has_index(), has_schema(), has_sequence(),  has_table(), info_cache, reflect_table(),  sort_tables_on_foreign_key_dependency()

类签名

sqlalchemy.engine.reflection.Inspectorsqlalchemy.inspection.Inspectable

method __init__(bind: Engine | Connection)

初始化一个新的Inspector

自版本 1.4 起已弃用:Inspector上的 init()方法已弃用,并将在将来的版本中删除。请使用EngineConnection上的inspect()函数来获取Inspector

参数:

bind – 一个Connection,通常是EngineConnection的实例。

对于Inspector的方言特定实例,请参阅Inspector.from_engine()

attribute bind: Engine | Connection
method clear_cache() → None

重置此Inspector的缓存。

具有数据缓存的检查方法在下次调用以获取新数据时将发出 SQL 查询。

版本 2.0 中的新功能。

attribute default_schema_name

返回当前引擎数据库用户的方言呈现的默认模式名称。

例如,对于 PostgreSQL 通常为public,对于 SQL Server 为dbo

attribute dialect: Dialect
attribute engine: Engine
classmethod from_engine(bind: Engine) → Inspector

从给定的引擎或连接构造一个新的特定于方言的 Inspector 对象。

自版本 1.4 起已弃用:Inspector上的 from_engine()方法已弃用,并将在将来的版本中删除。请使用EngineConnection上的inspect()函数来获取Inspector

参数:

bind – 一个ConnectionEngine

该方法与直接构造函数调用Inspector不同,因为Dialect有机会提供特定于方言的Inspector实例,该实例可能提供其他方法。

请参阅Inspector的示例。

method get_check_constraints(table_name: str, schema: str | None = None, **kw: Any) → List[ReflectedCheckConstraint]

返回table_name中关于检查约束的信息。

给定一个字符串table_name和一个可选的字符串模式,将检查约束信息作为ReflectedCheckConstraint的列表返回。

参数:

  • table_name – 表的名称字符串。对于特殊引用,请使用quoted_name
  • schema – 字符串模式名称;如果省略,则使用数据库连接的默认模式。对于特殊引用,请使用quoted_name
  • **kw – 传递给特定方言实现的其他关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典列表,每个字典代表检查约束的定义。

另见

Inspector.get_multi_check_constraints()

method get_columns(table_name: str, schema: str | None = None, **kw: Any) → List[ReflectedColumn]

返回table_name中关于列的信息。

给定一个字符串table_name和一个可选的字符串schema,返回列信息作为ReflectedColumn的列表。

参数:

  • table_name – 表的名称字符串。对于特殊引用,请使用quoted_name
  • schema – 字符串模式名称;如果省略,则使用数据库连接的默认模式。对于特殊引用,请使用quoted_name
  • **kw – 传递给特定方言实现的其他关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典列表,每个字典代表数据库列的定义。

另见

Inspector.get_multi_columns().

method get_foreign_keys(table_name: str, schema: str | None = None, **kw: Any) → List[ReflectedForeignKeyConstraint]

返回table_name中的外键信息。

给定一个字符串table_name和一个可选的字符串模式,返回外键信息作为ReflectedForeignKeyConstraint的列表。

参数:

  • table_name – 表的字符串名称。对于特殊引用,请使用quoted_name
  • schema – 字符串模式名称;如果省略,则使用数据库连接的默认模式。对于特殊引用,请使用quoted_name
  • **kw – 传递给特定方言实现的额外关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典列表,每个代表一个外键定义。

另请参阅

Inspector.get_multi_foreign_keys()

method get_indexes(table_name: str, schema: str | None = None, **kw: Any) → List[ReflectedIndex]

返回表table_name中索引的信息。

给定一个字符串table_name和一个可选的字符串模式,返回索引信息作为ReflectedIndex的列表。

参数:

  • table_name – 表的字符串名称。对于特殊引用,请使用quoted_name
  • schema – 字符串模式名称;如果省略,则使用数据库连接的默认模式。对于特殊引用,请使用quoted_name
  • **kw – 传递给特定方言实现的额外关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典列表,每个代表一个索引的定义。

另请参阅

Inspector.get_multi_indexes()

method get_materialized_view_names(schema: str | None = None, **kw: Any) → List[str]

返回模式中所有物化视图的名称。

参数:

  • schema – 可选,从非默认模式中检索名称。对于特殊引用,请���用quoted_name
  • **kw – 传递给特定方言实现的额外关键字参数。有关更多信息,请参阅正在使用的方言的文档。

2.0 版本中的新功能。

另请参阅

Inspector.get_view_names()

method get_multi_check_constraints(schema: str | None = None, filter_names: Sequence[str] | None = None, kind: ObjectKind = ObjectKind.TABLE, scope: ObjectScope = ObjectScope.DEFAULT, **kw: Any) → Dict[TableKey, List[ReflectedCheckConstraint]]

返回给定模式中所有表中检查约束的信息。

可通过将要用于filter_names的名称传递来过滤表。

对于每个表,值是一个ReflectedCheckConstraint列表。

参数:

  • schema – 字符串模式名称;如果省略,则使用数据库连接的默认模式。要进行特殊引用,请使用quoted_name
  • filter_names – 可选择性地仅返回列出的对象的信息。
  • kind – 指定要反映的对象类型的ObjectKind。默认为ObjectKind.TABLE
  • scope – 指定要反映默认、临时或任何表的约束的ObjectScope。默认为ObjectScope.DEFAULT
  • **kw – 传递给特定方言实现的额外关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典,其中键是两元组模式、表名,值是字典列表,每个字典表示检查约束的定义。如果未提供模式,则模式为None

新版本 2.0 中新增。

另请参见

Inspector.get_check_constraints()

method get_multi_columns(schema: str | None = None, filter_names: Sequence[str] | None = None, kind: ObjectKind = ObjectKind.TABLE, scope: ObjectScope = ObjectScope.DEFAULT, **kw: Any) → Dict[TableKey, List[ReflectedColumn]]

返回给定模式中所有对象中列的信息。

可通过将要使用的名称传递给filter_names来过滤对象。

对于每个表,值是一个ReflectedColumn列表。

参数:

  • schema – 字符串模式名称;如果省略,则使用数据库连接的默认模式。要进行特殊引用,请使用quoted_name
  • filter_names – 可选择性地仅返回列出的对象的信息。
  • kind – 指定要反映的对象类型的ObjectKind。默认为ObjectKind.TABLE
  • scope – 指定要反映默认、临时或任何表的列的ObjectScope。默认为ObjectScope.DEFAULT
  • **kw – 传递给特定方言实现的额外关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典,其中键是两元组模式、表名,值是字典列表,每个字典表示数据库列的定义。如果未提供模式,则模式为None

新版本 2.0 中新增。

另请参见

Inspector.get_columns()

method get_multi_foreign_keys(schema: str | None = None, filter_names: Sequence[str] | None = None, kind: ObjectKind = ObjectKind.TABLE, scope: ObjectScope = ObjectScope.DEFAULT, **kw: Any) → Dict[TableKey, List[ReflectedForeignKeyConstraint]]

返回给定模式中所有表中外键的信息。

可通过将要使用的名称传递给filter_names来过滤表。

对于每个表,该值是一个 ReflectedForeignKeyConstraint 列表。

参数:

  • schema – 字符串模式名称;如果省略,将使用数据库连接的默认模式。对于特殊引用,请使用 quoted_name
  • filter_names – 可选择仅返回此处列出的对象信息。
  • kind – 一个指定要反映的对象类型的 ObjectKind。默认为 ObjectKind.TABLE
  • scope – 一个指定是否应反映默认、临时或任何表的外键的 ObjectScope。默认为 ObjectScope.DEFAULT
  • **kw – 传递给特定方言实现的其他关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典,其中键是两元组模式、表名,值是字典列表,每个表示外键定义。如果未提供模式,则模式为 None

2.0 版中的新功能。

另请参阅

Inspector.get_foreign_keys()

method get_multi_indexes(schema: str | None = None, filter_names: Sequence[str] | None = None, kind: ObjectKind = ObjectKind.TABLE, scope: ObjectScope = ObjectScope.DEFAULT, **kw: Any) → Dict[TableKey, List[ReflectedIndex]]

返回给定模式中所有对象中索引的信息。

通过将要使用的名称传递给 filter_names 来过滤对象。

对于每个表,该值是一个 ReflectedIndex 列表。

参数:

  • schema – 字符串模式名称;如果省略,将使用数据库连接的默认模式。对于特殊引用,请使用 quoted_name
  • filter_names – 可选择仅返回此处列出的对象信息。
  • kind – 一个指定要反映的对象类型的 ObjectKind。默认为 ObjectKind.TABLE
  • scope – 一个指定是否应反映默认、临时或任何表的索引的 ObjectScope。默认为 ObjectScope.DEFAULT
  • **kw – 传递给特定方言实现的其他关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典,其中键是两元组模式、表名,值是字典列表,每个表示索引的定义。如果未提供模式,则模式为 None

2.0 版中的新功能。

另请参阅

Inspector.get_indexes()

method get_multi_pk_constraint(schema: str | None = None, filter_names: Sequence[str] | None = None, kind: ObjectKind = ObjectKind.TABLE, scope: ObjectScope = ObjectScope.DEFAULT, **kw: Any) → Dict[TableKey, ReflectedPrimaryKeyConstraint]

返回给定模式中所有表的主键约束的信息。

通过将要使用的名称传递给 filter_names 来过滤表格。

对于每个表,该值为 ReflectedPrimaryKeyConstraint

参数:

  • schema – 字符串模式名称;如果省略,则使用数据库连接的默认模式。要进行特殊引用,请使用 quoted_name
  • filter_names – 可选择仅返回此处列出的对象的信息。
  • kind – 一个指定要反映的对象类型的 ObjectKind。默认为 ObjectKind.TABLE
  • scope – 一个指定应反映默认、临时或任何表的主键的 ObjectScope。默认为 ObjectScope.DEFAULT
  • **kw – 要传递给特定方言实现的其他关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典,其键为二元组模式、表名,值为每个表示主键约束的定义的字典。如果未提供模式,则模式为 None

2.0 版中的新内容。

另请参见

Inspector.get_pk_constraint()

method get_multi_table_comment(schema: str | None = None, filter_names: Sequence[str] | None = None, kind: ObjectKind = ObjectKind.TABLE, scope: ObjectScope = ObjectScope.DEFAULT, **kw: Any) → Dict[TableKey, ReflectedTableComment]

返回给定模式中所有对象中表注释的信息。

可通过传递用于 filter_names 的名称来过滤对象。

对于每个表,该值为 ReflectedTableComment

对不支持注释的方言引发 NotImplementedError

参数:

  • schema – 字符串模式名称;如果省略,则使用数据库连接的默认模式。要进行特殊引用,请使用 quoted_name
  • filter_names – 可选择仅返回此处列出的对象的信息。
  • kind – 一个指定要反映的对象类型的 ObjectKind。默认为 ObjectKind.TABLE
  • scope – 一个指定应反映默认、临时或任何表的注释的 ObjectScope。默认为 ObjectScope.DEFAULT
  • **kw – 要传递给特定方言实现的其他关键字参数。有关更多信息,请参阅正在使用的方言的文档。

返回:

一个字典,其键为二元组模式、表名,值为表示表注释的字典。如果未提供模式,则模式为 None

2.0 版中的新内容。

另请参见

Inspector.get_table_comment()

method get_multi_table_options(schema: str | None = None, filter_names: Sequence[str] | None = None, kind: ObjectKind = ObjectKind.TABLE, scope: ObjectScope = ObjectScope.DEFAULT, **kw: Any) → Dict[TableKey, Dict[str, Any]]

返回指定了在给定模式中创建表时指定的选项的字典。

可通过传递用于 filter_names 的名称来过滤表。

目前包括适用于 MySQL 和 Oracle 表的一些选项。  


SqlAlchemy 2.0 中文文档(三十九)(2)https://developer.aliyun.com/article/1562608

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
5月前
|
SQL 关系型数据库 数据库
SqlAlchemy 2.0 中文文档(四十四)(9)
SqlAlchemy 2.0 中文文档(四十四)
59 3
|
5月前
|
SQL 缓存 关系型数据库
SqlAlchemy 2.0 中文文档(三十七)(2)
SqlAlchemy 2.0 中文文档(三十七)
49 2
|
5月前
|
SQL 存储 缓存
SqlAlchemy 2.0 中文文档(三十七)(4)
SqlAlchemy 2.0 中文文档(三十七)
58 1
|
5月前
|
SQL 缓存 API
SqlAlchemy 2.0 中文文档(三十七)(5)
SqlAlchemy 2.0 中文文档(三十七)
33 1
|
5月前
|
SQL 存储 缓存
SqlAlchemy 2.0 中文文档(三十七)(3)
SqlAlchemy 2.0 中文文档(三十七)
39 1
|
5月前
|
关系型数据库 数据库连接 数据库
SqlAlchemy 2.0 中文文档(三十九)(2)
SqlAlchemy 2.0 中文文档(三十九)
33 0
|
5月前
|
缓存 数据库连接 数据库
SqlAlchemy 2.0 中文文档(三十九)(4)
SqlAlchemy 2.0 中文文档(三十九)
37 0
|
5月前
|
关系型数据库 MySQL 数据库
SqlAlchemy 2.0 中文文档(三十九)(3)
SqlAlchemy 2.0 中文文档(三十九)
30 0
|
5月前
|
关系型数据库 MySQL 数据库
SqlAlchemy 2.0 中文文档(三十九)(5)
SqlAlchemy 2.0 中文文档(三十九)
31 0
|
5月前
|
关系型数据库 数据库连接 API
SqlAlchemy 2.0 中文文档(四十五)(3)
SqlAlchemy 2.0 中文文档(四十五)
128 0