永續性和事務框架開發 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）則不需要。同樣，垃圾回收是資料管理器的責任，而不是框架的責任。應用程式級別的完整性系統也會很有趣，但不會依賴於永續性系統。