Zope 2.13 の新機能¶
このページでは、このバージョンの Zope 2 の新しい高度な機能と変更点について 説明します。
新機能やバグ修正の細目については、 変更の詳細 を参照してください。
Python 2.7¶
このZope2リリースには Python 2.7 サポートが追加されています。Python 2.7 で何が変わったのかを詳しく知りたい場合は、 What’s new in Python 2.7 を参照してください。
Zope 2.13 はこれまでの Python 2.6.4 またはそれ以降のメンテナンスリリースバージョンを サポートしていきます。そして Python 3 以降のバージョンについては、現時点では サポートしません。Zope2の下層レイヤで使用している Zope Toolkit は Python 3 への対応を開始しています。
ZODB 3.10¶
このバージョンのZopeにはZODB 3.10というZODBの新しいメジャーバージョンを 同梱しています。大きな変化として様々な性能改善が行われています。 ZEOサーバーのプロセスはマルチスレッドになりました。このため、利用している ファイルシステムとDISKストレージが並列DISK I/Oを効率的に処理出来るので あれば最大4倍までスループットが増加するでしょう。これに関連して、 ソリッドステートディスク(SSD)をZEOサーバーに使うことで同様にスループット が向上するでしょう。両方を組み合わせることで16倍までのスループットを 得ることも可能です。
ファイルストレージのインデックスについてフォーマットが新しくなりました。 これにより、サイズが小さくなり読み込みが非常に速くなりました。repozoの バックアップスクリプトがデータだけでなくインデックスファイルもバックアップ するようになったため、復元した際にインデックスを再作成しなくてよくなりました。 大きなデータベースではインデックスの復元にかかる時間を省略できるため、 ダウンタイムの削減につながります。
ZODBにpickleデータを変換するためのラッパーストレージ機能が追加されました。 これには圧縮と暗号化の機能が含まれています。このストレージにzlibでの圧縮機能を 提供する zc.zlibstorage という新しいパッケージを使用できます。コンテンツ管理に使っている状況で、 データの多くがblobではなく文字列なのであれば、Data.fsサイズを半分以下に削減 させる効果を見込めます。圧縮や展開のオーバーヘッドコストは無視できる程度です。 この仕組みはネットワークI/Oとディスクスペースの両方に効果があります。 そしてデータベースにとってより重要なのは、OSのディスクキャッシュやメモリに 乗る可能性が高くなったことです。SSDを使っている場合は、2つめのアドバンテージは それほど重要ではありません。
Databaseに16MB以上の大きなデータを保存しようとすると警告されるようになりました。 これは設計の間違いなどを警告する試みです。これに関連して新しいオプション (large_record_size/large-record-size) で警告するレコードサイズを指定します。 こういった部分はこれまでは透過的に開発者には見えないようにしていましたが、 これによって開発者がストレージ周りの実装コードについてより理解する助けに なると思います。
mkzopeinst スクリプトは zope.mkzeoinstance という別プロジェクトに分割され、ZODBパッケージには含まれなくなりました。 このためZEO環境を作る必要がある場合にはこのパッケージをインストールするか、 buildout を使っているのであれば plone.recipe.zeoserver レシピを使って下さい。
より詳細な情報を知りたい場合は change log. を参照して下さい。
WSGI¶
このバージョンのZopeからWSGIを標準サポートします。WSGIの先駆者は repoze.zope2プロジェクトでしたが、ここで最終的に得られた技術をZopeのコア に取り込むことが出来たため、外部プロジェクトを使わなくてもよくなりました。 WSGIをZope2標準で使えるようになったため、様々なWebサーバーと連携するために ZServerの制約を受ける事がなくなりました。これはさらにZope2用のミドルウェア を作成したり再利用したり、Zope2をWSGIのパーツとして提供するなどの、 新しい可能性を開きます。将来的にはこのデプロイ方式が標準となっていき、 古いZServerでの方式は廃止されるでしょう。これについての具体的なスケジュール はまだ決まっていません。
ノート: WSGI用のセットアップドキュメントや現代的なインスタンス作成手順はまだ ありません。もしこの機能を試してみるのであればそこで何が起きるのかを正確に 知っていることが期待されます。
Zope Toolkit¶
Zope 2.13 には直接的にも間接的にも zope.app.* への依存はもうありません。 これでZope2と3のコードべース融合への移行は完了しました。Zope3自体も2つの プロジェクトに分割され、片方はZope Toolkitという基本ライブラリ部分となり、 もう片方はアプリケーションサーバー部分です。アプリケーションサーバー部分は BlueBreamと名付けられました。Zope2はZope Toolkitにのみを同梱し依存しています。
Zope2のコードの多くの部分を占めていたProducts.FiveはZope Toolkitの利用に 向けてリファクタリングしていきます。最終的なゴールはFiveインテグレーション層 を取り除き、Zope ToolkitをZope2から直接使うようにすることです。
ZCatalog¶
ZCatalogと、そこで使われる標準のインデクサを実装しているPluginIndexes パッケージには大幅な変更が加えられました。その多くは昨年までにZope コミュニティーでアドオンパッケージとして開発されてきたもので、それらが 正式にコアパッケージに取り込まれました。最も大きな変更は、カタログの クエリ実行計画のサポートが追加されたことです。全てのリレーショナル データベースの標準の機能におけるクエリ実行計画の仕事は、クエリを実際に システム上で実行する時の状態を監視して、測定基準となるデバイスで クエリ結果を導き出すための低レベルのコードの実行を最適化します。
クエリ実行計画サポートは完全に透過的に全てのユーザーに提供されます。 しかし開発者がその動作を事前定義しておくこともでき、それはサーバー再起動時 にも保持されます。実行計画はZMIのタブで確認することが出来ます。また、 この新しいZMIタブでは、時間のかかっているカタログクエリが報告され、 開発者がアプリケーションの速度改善に役立てられるようになりました。
こういった大きな変更の他に、数多くの細かい変更が検索ロジックやカタログ実装 などに対して行われています。これらの変更全ては、より良い検索結果を得る事と コンフリクトエラーが発生する可能性の軽減のために行われました。
リファクタリング¶
Zope2を独立したモジュールにするためにさらなるリファクタリングの努力が続けられて います。Zope2.12で既に多くのリファクタリングが行われ、分割されたzope.*パッケージ を使い、Zope2自身もAcquisition, DateTime, tempstorageなどのパッケージを分割 しました。Zope2.13はこの流れを進め、C拡張モジュールを含むパッケージを配布物 から分割しました。これに該当するのが AccessControl, DocumentTemplate, Products.ZCTextIndex です。
Formlibサポートのオプション化¶
Zope2はいくつかのフレームワークをProducts.Fiveというインテグレーション層で 統合して構成されています。このうちの一つに、zope.formlibというフォームを 自動生成するフレームワークがあり、これにzope.app.form Widgetライブラリが 付いてきます。
このフォーム生成フレームワークはZopeコミュニティーの中ではあまりメジャーではなく、 より一般的な選択肢としてz3c.formなどがあります。これを反映して、Zope2はformlib を直接同梱するのをやめました。
もしformlibが必要であれば、新しいfive.formlibへの依存設定を追加し、他にも Products.Five.formやProducts.Five.fromlibをimportしている箇所をこの新しい パッケージをimportするように変更して下さい。
five.formlibは既に2.12リリースとの後方互換性があるので、簡単に移行を始められます。 Zope2.12.3でfive.formlibパッケージを使うとProducts.Fiveが無効化されます。 このため、あなたのパッケージを2.12と2.13の両方に簡単に対応させることができる ようになります。
(Translated by Shimizukawa, r114672, original-site)
