アプリケーションへデータベースの変更を行う場合、データアップグレードプロセスを使用して、ユーザーの既存データを新しいデータベーススキーマに移行する必要があります。 古いフレームワークでは複数のクラスが必要でしたが、新しいフレームワークでは単一のクラスからアップグレード手順を調整できます。 1つのクラスのステップを管理すると、アップグレードプロセスの開発が容易になります。 使用するデータアップグレードフレームワークは、開発フレームワークによって異なります。 このチュートリアルでは、新しいフレームワークに移行する方法を示します。
-
アップグレードされたプラグインが従来のWARである場合、特別なことをする必要はありません。Liferay DXP 7.1のAPIに適合した既存のアップグレードプロセスはそのまま機能します。 新しいデータアップグレードフレームワークはモジュール専用です。
-
アップグレードしたプラグインをモジュールに変換した場合、またはアップグレードしたモジュールがある場合、引き続き使用するアップグレードプロセスを新しいデータアップグレードフレームワークに移行する必要があります。
（最新のものから始まる）古いアップグレードプロセスをいくつでも新しいフレームワークに移行できます。 たとえば、モジュールにバージョン1.0、1.1、1.2、および1.3があり、バージョン1.2以降の顧客のみがアップグレードすることを予期している場合、バージョン1.2および1.3のみのアップグレードプロセスを移行できます。
開始する前に新しいフレームワークを使用してアップグレードプロセスを作成する方法を参照してください。
まず最初に、Liferay Portal 6のアップグレードプロセスの仕組みを確認します。
Liferay Portal 6のアップグレードプロセスについて
始める前に、Liferay Portal 6のアップグレードプロセスがどのように構成されているかを理解することが重要です。 例として、Liferay Portal 6.2のアップグレードプロセスをナレッジベースポートレットのために使用します。
Liferay Portal 6のアップグレードプロセスでは、各スキーマバージョンのアップグレードステップクラスは、スキーマバージョンに基づいて名前が付けられたフォルダの中にあります。 たとえば、ナレッジベースポートレットのアップグレードステップクラスは、v1_0_0、v1_1_0、v1_2_0などのフォルダ名の中にあります。 各アップグレードステップクラスは、UpgradeProcessを拡張し、doUpgrade メソッドをオーバーライドします。 doUpgradeのコードがアップグレードを実行します。 たとえば、ナレッジベースポートレットのv1_0_0/UpgradeRatingsEntryアップグレードステップはUpgradeProcessを拡張し、そのdoUpgradeメソッドでのupdateRatingsEntries()呼び出しを介してアップグレードを実行します。
public class UpgradeRatingsEntry extends UpgradeProcess {
@Override
protected void doUpgrade() throws Exception {
updateRatingsEntries();
}
...
protected void updateRatingsEntries() throws Exception {
// Upgrade code
}
...
}
アップグレードプロセスクラスは、アップグレード手順を含むフォルダと同じレベルにあり、スキーマバージョンに基づいて名前が付けられます。 たとえば、ナレッジベースポートレットのアップグレードプロセスクラスの名前は、UpgradeProcess_1_0_0、UpgradeProcess_1_1_0、UpgradeProcess_1_2_0などとなります。 各アップグレードプロセスクラスはUpgradeProcessを拡張し、doUpgradeメソッドでアップグレードプロセスを実行します。 適切なアップグレードプロセスをupgradeメソッドに渡すことにより、アップグレードプロセスを実行します。 たとえば、ナレッジベースポートレットのUpgradeProcess_1_0_0クラスにあるdoUpgradeメソッドは、upgradeメソッドを介して、アップグレード手順UpgradeRatingsEntryおよびUpgradeRatingsStatsを実行します。
@Override
protected void doUpgrade() throws Exception {
upgrade(UpgradeRatingsEntry.class);
upgrade(UpgradeRatingsStats.class);
}
ここまで、Liferay Portal 6のアップグレードプロセスの定義方法について学びました。次に、Liferay DXP 7.1でそれらを新しいアップグレードプロセスフレームワークに変換する方法について学びます。
Liferay Portal 6アップグレードプロセスをLiferay DXP 7.1に変換する
Liferay Portal 6のアップグレードプロセスは、新しいアップグレードプロセスフレームワークを使用するプロセスと、どのように比較できるでしょうか。 まず、アップグレード手順のクラスは同じであるため、変更せずにそのままにしておくことができます。 新しいアップグレードプロセスの大きな変更点は次のとおりです。
登録クラスを作成して、変換を開始します。
登録者クラスを作成する
新しいデータアップグレードフレームワークでは、アップグレードプロセスクラスの代わりに登録クラスを使用する必要があります。 また、アップグレードプロセスクラスの機能を単一の登録クラスに結合する必要があります。 アップグレードプロセスフレームワークが実行するアップグレードプロセスを、登録者が定義することの詳細については、the data upgrade process tutorialを参照してください。 登録者のregistry.register呼び出しごとに、スキーマバージョンごとに適切なアップグレード手順が登録されます。 したがって、古いアップグレードプロセスクラスのdoUpgradeメソッドの機能を、登録者のregistry.register呼び出しに転送する必要があります。
例として、GitHubのナレッジベースポートレットの新しいLiferay DXP 7.1アップグレードプロセスを参照するには、ここをクリックしてください。
Liferay DXP 7.1用のポートレットに加えられた変更を処理するいくつかの追加のアップグレードステップクラス以外で、このアップグレードプロセスの唯一の違いは、複数のアップグレードプロセスクラスの代わりに単一の登録クラスKnowledgeBaseServiceUpgradeを含むことです。 KnowledgeBaseServiceUpgradeクラスはすべての登録者と同様に、その registry.register呼び出しで、各スキーマバージョンに向けた適切なアップグレード手順を呼び出します。 たとえば、最初のregistry.register呼び出しは、1.0.0スキーマバージョンのアップグレードプロセスを登録します。
registry.register(
"com.liferay.knowledge.base.service", "0.0.1", "1.0.0",
new com.liferay.knowledge.base.internal.upgrade.v1_0_0.
UpgradeRatingsEntry(),
new com.liferay.knowledge.base.internal.upgrade.v1_0_0.
UpgradeRatingsStats());
これを上記のLiferay Portal 6対応アップグレードプロセスクラスUpgradeProcess_1_0_0からのdoUpgradeメソッドと比較します。 どちらも同じアップグレード手順を呼び出します。
次に、モジュール化されたプラグインがService Builderを使用する場合、Bundle Activatorを作成します。
Bundle Activatorを作成する
モジュールがService Builderサービスを実装する場合、リリーステーブルのレコードを初期化するためにBundle Activatorが必要です。 Bundle Activatorの作成は簡単です。
これで完了です。\ 登録者の作成の完全な手順を含む、Liferay DXP 7.1の新しいアップグレードプロセスの作成手順については、ここをクリックしてください。