新闻和更新

SQLAlchemy 2.0.0，SQLAlchemy 2.0 的首个生产版本，现已发布。

在此版本中，当运行以下命令时，默认安装的 SQLAlchemy 版本将是pip install sqlalchemy将是 2.0 版本。请注意，与 1.4 系列相比，2.0 版本具有重大的 API 更改，因此在 SQLAlchemy 1.x 系列上运行且尚未完成 迁移过程 的应用程序应确保设置 requirements 以保持所需的 SQLAlchemy 主要发布系列。

SQLAlchemy 2.0 系列的历史始于四年多前的 2018 年 8 月 8 日，当时有一些关于如何统一 SQLAlchemy 的 Core 和 ORM 查询概念的简短想法。真正的“SQLAlchemy 2.0”概念的第一个计划于当年 11 月形成，重点关注两个领域：大幅简化 Core 执行和事务 API，以及寻求统一 Core 和 ORM 之间的查询。

对基础概念的更改非常巨大，以至于 SQLAlchemy 2.0 被分为两个主要阶段。第一阶段是 SQLAlchemy 1.4 系列，它提供了一个全新的统一的 Core / ORM SQL 查询系统，同时构建在新的通用语句缓存架构之上。此阶段为 SQLAlchemy 2.0 的 SQL 构建方法（减去 pep-484 类型支持）提供了完整的实现，同时保留了传统的QueryAPI。与此版本一起，我们提供了一个全面的 迁移路径，其灵感来自 Python 2->3 迁移过程中吸取的教训，该路径描述了如何移植应用程序，以便它们可以在 SQLAlchemy 1.4 中继续运行，同时完全向前兼容 SQLAlchemy 2.0。

第二阶段是 SQLAlchemy 2.0 系列，它移除了大部分已弃用的元素，将剩余的元素（主要是Query）置于长期“遗留”状态，完全迁移到仅支持 Python 3，同时添加了许多基于新架构构建的新功能，充分利用了 Python 3 的特性（包括 dataclasses、枚举、内联注解）以及新的统一查询架构。

这种方法的关键优势在于，最重要且风险最高的架构更改，即在新的缓存层之上重写 Core/ORM 查询，已经在 SQLAlchemy 1.4 中生产环境使用了近两年。因此，虽然 SQLAlchemy 2.0 一旦被所有开发者受众使用肯定会出现许多新问题，但它们不应该是“基础方法出现新裂缝”的那种问题，因为架构基础已经得到广泛使用。我们预计，绝大多数问题将与新的类型系统以及现有应用程序调整以使用新 API 的问题有关。

SQLAlchemy 2.0 是一个足够大的版本，它有 两份 迁移指南；主要迁移指南 记录了如何实现 API 兼容性，以便应用程序能够平等地在 SQLAlchemy 1.4 或 2.0 中运行；SQLAlchemy 2.0 中的新功能？ 指南然后提供了应用程序在 SQLAlchemy 2.0 上运行时可用的所有新功能和 API。

考虑到以上介绍，以下是 SQLAlchemy 2.0 中的全新功能的顶级项目符号列表

• 全新的无插件 pep-484 兼容 ORM 语法 - ORM 声明式映射器配置风格现在有了全新的外观，大量借鉴了 Python dataclasses 和 SQLModel 等系统，以提供 注解驱动的 ORM 声明，使用 pep-484 注解的运行时解释来生成完全类型化并与任何类型检查器或 IDE 兼容的映射类。
• pep-484 支持新式和旧式 ORM 查询 - 使用 Annotated Declarative 模型，创建的 SQL 构造，例如select()对象或旧式Query构造，它们本身被类型化为行中返回的列的类型，并且这种类型化一直延续到从执行查询后返回的结果对象中提取的 Python 值。虽然 Python 类型化在做这类事情方面仍然存在局限性，但新的类型支持借鉴了 SQLModel 使用的一些技术，使其在没有额外注解的情况下适用于从 ORM 模型类生成的大多数查询，并且对面向 Core 或混合 Core/ORM 查询的结果集类型化也提供不同程度的支持。一些示例位于 SQL 表达式类型化 - 示例。
• 声明式与 Python Dataclasses 完全集成 - SQLAlchemy 2.0 引入了对将 Annotated Declarative 映射类直接生成为 Python dataclass 的支持；这将提供一个像任何其他类一样声明的 ORM 映射类，该类具有自动生成的 dataclasses 方法，例如__init__(), __repr__(), __eq__()，以及所有其他方法。这种 新方法 比 SQLAlchemy 1.4 中引入的临时“混合”方法有了极大的改进。
• 一种全新的、完全 ORM 集成的批量 INSERT 方法，在大多数后端通常快一个数量级 - SQLAlchemy 支持的大多数数据库和驱动程序现在已经添加或改进了对INSERT RETURNING语法的支持，SQLAlchemy 2.0 通过支持和改进所有后端的 RETURNING 支持来利用这一点，唯一的例外是 MySQL（仅限 MySQL；MariaDB 支持 RETURNING）。这种改进的一部分是能够在一个批处理语句中 INSERT 数千行，该语句还返回 ORM 所需的服务器生成值的完整结果集，这在以前是不可能的，唯一的例外是依赖于psycopg2驱动程序。在 2.0 中，已经完成了优化INSERT所有后端，以便 数千个带有或不带有主键的 ORM 对象可以通过一次数据库往返 INSERT，并且此功能已完全集成到 ORM 中，用于所有 INSERT 操作，包括“常规”ORM 工作单元操作以及“批量”方法，这些方法也在 2.0 版本中进行了 新修订。
• 一种全新的批量优化的模式反射架构 - 反射完整模式的操作，例如MetaData.reflect(engine)以及新添加的模式范围操作，使用inspect(engine)构造现在构建在这样一个基础之上：它假设操作可以一次处理数百或数千个表，而不是一次处理一个表。方言可以通过提供新的反射查询来“选择加入”新架构，这些查询可以一次处理多个表，从而可以更有效地完全反射非常大的模式。新架构已为 PostgreSQL 和 Oracle 后端 启用，这两个后端在大型模式方面存在最大的性能问题，其中 PostgreSQL 提高了 250%，Oracle 提高了 900%。SQL Server 方言是新架构的下一个目标。任何第三方方言都可以选择加入新的“一次多个表”系统，或者保留以前的“一次一个表”方法，该方法仍然完全兼容，没有任何更改。
• 原生扩展移植到 Cython - SQLAlchemy 的 C 扩展已替换为使用 Cython 的更新方法。在大多数情况下，Cython 版本的扩展与之前的 C 扩展一样快，有时甚至更快，并且使 SQLAlchemy 能够更轻松地在库的更多领域提供新的原生扩展，而不会有内存或稳定性问题的风险。

SQLAlchemy 2.0 包含更多功能，并且随着新架构和许多旧包袱的卸载，希望为未来留有充足的空间。

2.0.0 的详细更新日志链接位于 更新日志 - 请注意，2.0 系列更新日志跨越了四个 beta 版和三个候选发布版。

SQLAlchemy 2.0.0 可在 下载页面 上获取。