持久性和事务框架开发 SIG

最近新闻

在 O'Reilly 开源大会上将有一个 Python 持久性 BOF。

Python 持久性
日期：2002年7月25日
时间：晚上8:00 - 晚上10:00
地点：东塔 Grande Ballroom C
主持人：Patrick O'Brien，Orbtech

最近成立了一个 Python 持久性特殊兴趣小组，旨在探索将基本的持久性和事务机制添加到 Python 核心的方法，以避免各种具有类似问题的项目重复工作。本次 BOF 将允许参与者亲自思考 Python 持久性问题。此外，欢迎任何有兴趣与 Jim Fulton 和 Guido van Rossum 进行非正式 Python 持久性早餐讨论的人士，于周三早上 7 点在 O'Reilly 食品帐篷与我们一起参加。

章程

问题

透明性

应用程序不应必须显式跟踪对象更改或保存对象。应用程序不应必须显式查询大多数对象。通常，将显式检索一些“根”对象，并通过正常的 Python 对象遍历检索其他对象。应用程序对象不应包含提供其持久性所需的存储代码，例如 SQL 语句或文件操作。应用程序代码可能需要包含生成与持久性相关的事件的代码，但即使这些也应尽可能自动化，例如通过监视属性访问。

事务性存储

数据应以事务方式存储，并支持回滚更改。应预期支持（可选）嵌套事务。

有效内存使用

应用程序不应使用过多的内存。通常，持久性应用程序使用的数据过大，无法放入内存。对象仅在必要时才应加载，并且在不再需要时应从内存中删除。

这些工作大多集中在使用关系数据库数据提供持久性。这些工作在很大程度上是独立进行的。每个都将尝试独立解决上述要求，从而导致大量重复工作。

Zope 对象数据库 (ZODB) 一段时间以来一直满足上述要求。ZODB 目前正在经历从基于 ExtensionClass 的 ZODB 3 到基于 Python 2.2 新式类的 ZODB 4 的过渡。作为这项工作的一部分，ZODB 持久性和事务框架正在从 ZODB 中分离出来，放入单独的包中，希望它们对其他基于持久性的框架有用。

如果每个不同的持久性项目都必须独立解决上述要求，那将是巨大的重复工作。更糟糕的是，生成的系统将具有不太可能互操作的独立框架。为某个框架构建的对象需要重写才能与其他框架一起使用。

提案

建议成立一个新的持久性 SIG，以探索并尽可能生成可用于各种持久性实现（包括基于关系数据库的持久性和 ZODB）的持久性和事务框架。

协调员：Jeremy Hylton

结论：当框架的 1.0 版本交付时，或 2003 年 9 月 1 日，以较早者为准。

可交付成果：记录创建的框架的 PEP 和实现框架关键部分的软件。

假设可以定义一个令人满意的框架，则应将该框架和核心实现包含在标准 Python 发行版中。

范围

• 事务协调
• 基本的持久性管理，特别是观察对象更改（以了解何时需要保存对象）和访问（以了解何时使用对象以便从内存中删除未使用的对象），以及
• 激活和缓存，以便在需要时将对象移入内存，并在不再需要时移出内存。

范围 *不* 包括

• 并发控制。这是插入到框架中的特定数据管理器的责任。事务管理器仅跟踪对象更改并协调数据管理器的活动，以原子方式提交（或回滚）更改。
• 查询语言。各个数据管理器或应用程序可能会提供查询工具。虽然拥有一个用于 Python 的通用查询工具会很酷，并且我会支持这样一个项目，但这将是一个与此项目不同的项目。
• 完整性约束。某些数据管理器（例如基于关系数据的管理器）将需要提供用于低级别完整性检查的工具，而其他数据管理器（例如 ZODB）则不需要。同样，垃圾回收是数据管理器的责任，而不是框架的责任。应用程序级别的完整性系统也会很有趣，但不会依赖于持久性系统。