lablab.jp （日本語版）

Legacy モジュールはモジュールアップグレードのための新しい仕様を実装しました。 XOOPS2 JP において、アップデートスクリプトの仕様がアップグレードステップに対して十分ではなかったため、モジュール開発者は彼らのモジュールを自在にアップグレードすることができませんでした。モジュールの歴史の上では、多くのことが変更されます。 DB テーブルへの新しいフィールドの追加、モジュールへの新しいブロックの追加、コールバック関数の改名やリソースの除外…… XOOPS JP はこれらの情報を厳密な定義なしで自動的に更新しようと試みます。すなわち、そこに厳密なルールはありません。そのため、モジュール開発者は XOOPS2 JP がどのようにモジュールを更新するかを調べるために XOOPS2 JP を探索しなければなりませんでした。

ベータ３で、 Legacy System モジュールは vBulletin ライクな段階的アップグレードモード (phased upgrade mode) を導入しました。このモードでは、アップグレードはマイルストーン・バージョンに制限されます。たとえば、以下のような悪魔的なチェンジログを持つモジュールがあるとします。

• v0.10 初版 (varchar(255)の value フィールドが DB テーブルに存在)
• v0.20 新たに整数フィールド 'value2' をテーブルに追加
• v0.30 既存フィールド 'value' を DB テーブルから削除
• v0.35 'value2' を 'value' に改名

この悪魔的なチェンジログに対して、あなたはどのようにコールバック関数を書きますか？　不可能ではありませんが、それはとても困難です。大半のプログラマは XOOPS2 JP のよくないスペックと格闘することに時間を浪費したいと思わないでしょうから、大胆な変更は失われていきます。

段階的アップグレードは、アップグレードを複数のプロセスに分割することを可能にします。この例であれば、

1) v1.0 -> v2.0 upgrade
2) v2.0 -> v3.0 upgrade
3) v3.0 -> v3.5 upgrade

この方法により、ユーザーはいかなるバージョンからも正常に最新版へアップグレードすることができます。そして、モジュール開発者は Legacy System モジュールの自動的不正確アップグレード機能を抑制することができます。

モジュール・アップデート機能はベータ３より Legacy_PhasedUpgrader クラスを使用します。モジュール開発者が段階的アップグレード(phased upgrade)を望む場合、彼は Legacy_PhasedUpgrader のサブクラスを宣言しなければなりません。彼はクラスの全メソッドをオーバーライドすることができますが、 Legacy_PhasedUpgrader はモジュール開発者が段階的アップグレードを容易に実現できるように設計されています。したがって、マイルストーンバージョン番号とそのバージョンへのコールバックメソッドを定義するだけでよいでしょう。

Example Module "upgradeTest":

1. まずはじめに、 upgradeTest-0.10 をインストールしてください
   
2. 次に、 upgradeTest-0.35 をアップロードし、それからこのモジュールをアップデートしてください。
   
3. あなたは三段階でアップグレードしなければならないでしょう。

この例のチェンジログは上の悪魔的チェンジログです。しかし、あなたは以下のようなステップで正確にアップグレードを達成するでしょう。

(1) upgradeTest 0.10 -> upgradeTest 0.20 (Phased Upgrade) -> (2)
(2) upgradeTest 0.20 -> upgradeTest 0.30 (Phased Upgrade) -> (3)
(3) upgradeTest 0.30 -> upgradeTest 0.35

upgradeTest-0.35 はモジュール開発者のための良いサンプルです。