以前のバージョンでのアップグレードプロセスの使用
Liferay DXP 7.4 U10/Portal 7.4 GA14 以前のバージョン
モジュールのアップグレードプロセスを作成するには、以下の手順に従ってください。
-
モジュールの
bnd.bndファイルを開き、新しいスキーマ バージョン値を指定してLiferay-Require-SchemaVersionヘッダーを指定します。 新しいスキーマがバージョン1.1であるモジュールのスキーマバージョンヘッダーの例を以下に示します。Liferay-Require-SchemaVersion: 1.1重要Liferay-Require-SchemaVersionヘッダーが指定されていない場合、Liferay はBundle-Versionヘッダーの値をデータベース スキーマ バージョンとみなします。 -
モジュールの依存関係管理ファイル (Maven POM、Gradle ビルド ファイル、または Ivy
ivy.xmlファイル) に、com.liferay.portal.upgradeへの依存関係と、アップグレード プロセスに必要なその他のモジュールを追加します。build.gradleファイルの構成例を以下に示します。compile group: "com.liferay", name: "com.liferay.portal.upgrade.api", version: "2.0.3" -
UpgradeProcessベース・クラス (UpgradeStepインターフェイスを実装) を継承するUpgradeProcessクラスを作成します：public class MyUpgradeSchemaClass extends UpgradeProcess { ... } -
UpgradeProcessクラスのdoUpgrade()メソッドをオーバーライドして、データベースを変更する手順を指定します。 SQL コマンドと SQL DDL を実行するには、それぞれrunSQLメソッドとrunSQLTemplate*メソッド (BaseDBProcessクラスから継承) を使用します。 SQLファイルからDDL文を実行してテーブルやインデックスを作成、変更、または削除する場合は、必ずANSI SQLのみを使用してください。 こうすることで、異なるデータベースでもコマンドが正しく動作することが保証されます。 ANSI 以外の SQL を使用する必要がある場合は、UpgradeProcessクラスのrunSQLまたはalterメソッドに記述し、文を異なるデータベースに移植できるトークンを一緒に使用するのが最善です。これは、journal-service モジュールのUpgradeSchemaアップグレード ステップ クラスでrunSQLTemplateStringメソッドを使用して実行することで示されます。 SQL ファイルからの ANSI SQL DDL、alterメソッド、およびUpgradeProcessのUpgradeProcess.AlterColumnNameおよびUpgradeProcess.AlterColumnType内部クラスをトークン クラスとして使用して、列名と列の型を変更します。public class UpgradeSchema extends UpgradeProcess { @Override protected void doUpgrade() throws Exception { String template = StringUtil.read( UpgradeSchema.class.getResourceAsStream("dependencies/update.sql")); runSQLTemplateString(template, false, false); upgrade(UpgradeMVCCVersion.class); alter( JournalArticleTable.class, new AlterColumnName( "structureId", "DDMStructureKey VARCHAR(75) null"), new AlterColumnName( "templateId", "DDMTemplateKey VARCHAR(75) null"), new AlterColumnType("description", "TEXT null")); alter( JournalFeedTable.class, new AlterColumnName("structureId", "DDMStructureKey TEXT null"), new AlterColumnName("templateId", "DDMTemplateKey TEXT null"), new AlterColumnName( "rendererTemplateId", "DDMRendererTemplateKey TEXT null"), new AlterColumnType("targetPortletId", "VARCHAR(200) null")); } }com.liferay.calendar.serviceモジュールからのより簡単なアップグレード手順の例を以下に示します。 これは、alterメソッドを使用して、カレンダー予約テーブルの列タイプを変更します。public class UpgradeCalendarBooking extends UpgradeProcess { @Override protected void doUpgrade() throws Exception { alter( CalendarBookingTable.class, new AlterColumnType("description", "TEXT null")); } } -
アプリケーションが以前の従来の Liferay プラグイン アプリケーション (アプリケーション WAR) からモジュール化され、Service Builder を使用している場合は、バンドル アクティベーターを作成して登録し、Liferay の
Release_テーブルに登録します。 -
UpgradeStepRegistratorインターフェイスを実装する、サービス型UpgradeStepRegistrator.classのUpgradeStepRegistratorOSGi コンポーネント・クラスを作成します：package com.liferay.mycustommodule.upgrade; import com.liferay.portal.upgrade.registry.UpgradeStepRegistrator; import org.osgi.service.component.annotations.Component; @Component(immediate = true, service = UpgradeStepRegistrator.class) public class MyCustomModuleUpgrade implements UpgradeStepRegistrator { } -
モジュールのアップグレード登録を実装するために、
registerメソッドをオーバーライドします。—あるスキーマバージョンから次のスキーマバージョンにデータベースを更新するために必要なアップグレード手順を抽象化します。 例えば、アップグレード手順レジストラクラスMyCustomModuleUpgrade(下記) は、スキーマバージョンごとに 3 つのアップグレード手順を段階的に登録します (過去と現在、0.0.0から2.0.0、1.0.0から1.1.0、および1.1.0から2.0.0）。モジュールが以前にインストールされていない場合は、最初の登録が適用されます。 これには空のアップグレード手順が 1 つだけ含まれています: 新しい
DummyUpgradeStep。 この登録により、モジュールの最新のスキーマ バージョン (つまり、2.0.0) が Liferay のRelease_テーブルに記録されます。 同じクラス名が複数のパッケージで使用される場合は、クラスに対して完全修飾クラス名を指定する必要があります。これは、1.0.0から1.1.0) のUpgradeFooクラスについて以下に示すとおりです。package com.liferay.mycustommodule.upgrade; import com.liferay.portal.upgrade.registry.UpgradeStepRegistrator; import org.osgi.service.component.annotations.Component; @Component(immediate = true, service = UpgradeStepRegistrator.class) public class MyCustomModuleUpgrade implements UpgradeStepRegistrator { @Override public void register(Registry registry) { registry.register( "com.liferay.mycustommodule", "0.0.0", "2.0.0", new DummyUpgradeStep()); registry.register( "com.liferay.mycustommodule", "1.0.0", "1.1.0", new com.liferay.mycustommodule.upgrade.v1_1_0.UpgradeFoo()); registry.register( "com.liferay.mycustommodule", "1.1.0", "2.0.0", new com.liferay.mycustommodule.upgrade.v2_0_0.UpgradeFoo(), new UpgradeBar()); } }重要Service Builder を使用するモジュールは、Service Builder が既にスキーマ バージョンを Liferay の
Release_テーブルに記録しているため、初期データベース スキーマ バージョンの登録を 定義すべきではありません。 ただし、Service Builder を使用しないモジュールは、 初期スキーマの登録を 定義する必要があります。 -
アップグレード手順で OSGi サービスを使用する場合、 アップグレードはそのサービスが利用可能になるまで待機する必要があります。 レジストラ クラスが依存するクラスを宣言するには、
@Referenceアノテーションを使用します。 例えば、以下のWikiServiceUpgradeレジストレータ クラスは、SettingsFactoryクラスを参照し、UpgradePortletSettingsアップグレード ステップを実行します。setSettingsFactoryメソッドの@Referenceアノテーションは、レジストラ クラスがSettingsFactoryサービスに依存しており、実行時環境でそのサービスが利用可能になるまで待機する必要があることを宣言しています。@Component(immediate = true, service = UpgradeStepRegistrator.class) public class WikiServiceUpgrade implements UpgradeStepRegistrator { @Override public void register(Registry registry) { registry.register("0.0.1", "0.0.2", new UpgradeSchema()); registry.register("0.0.2", "0.0.3", new UpgradeKernelPackage()); registry.register( "0.0.3", "1.0.0", new UpgradeCompanyId(), new UpgradeLastPublishDate(), new UpgradePortletPreferences(), new UpgradePortletSettings(_settingsFactory), new UpgradeWikiPage(), new UpgradeWikiPageResource()); registry.register("1.0.0", "1.1.0", new UpgradeWikiNode()); registry.register( "1.1.0", "1.1.1", new UpgradeDiscussionSubscriptionClassName( _subscriptionLocalService, WikiPage.class.getName(), UpgradeDiscussionSubscriptionClassName.DeletionMode.ADD_NEW)); registry.register( "1.1.1", "2.0.0", new BaseUpgradeSQLServerDatetime( new Class<?>[] {WikiNodeTable.class, WikiPageTable.class})); } @Reference private SettingsFactory _settingsFactory; @Reference private SubscriptionLocalService _subscriptionLocalService; } -
サービスの提供を開始する前に、データベースを最新のデータベーススキーマバージョンにアップグレードしてください。 これを行うには、Bnd ヘッダー
Liferay-Require-SchemaVersionを Service Builder サービスの最新のスキーマ バージョンに設定します。 その他のすべてのサービスについては、包含モジュールとその最新のスキーマ バージョンを対象とする@Referenceアノテーションを指定します。ターゲットに必要な属性は以下のとおりです。
release.bundle.symbolic.name: モジュールのバンドルシンボル名release.schema.version: モジュールの現在のスキーマバージョン
例えば、
com.liferay.comment.page.comments.webモジュールのPageCommentsPortletクラスは、以下の参照を定義することで、スキーマ バージョン2.0.0にアップグレードされます。@Reference( target = "(&(release.bundle.symbolic.name=com.liferay.comment.page.comments.web)(release.schema.version=2.0.0))" ) private Release _release;OSGiサービス間の依存関係により、アップグレード参照注釈が必要となるサービスクラスの数を減らすことができます。 例えば、依存関係にあるサービスが既にアップグレードを参照している場合、そのサービスにアップグレード参照を追加する必要はありません。
注記クラス
VerifyProcessを使用したデータ検証は非推奨です。 検証はスキーマのバージョンと関連付けるべきである。 アップグレード プロセスはスキーマ バージョンに関連付けられていますが、VerifyProcessインスタンスは関連付けられていません。
これで、すべてのモジュールのデータアップグレードを作成する方法がわかりました。
モジュールアップグレードライフサイクル
Liferay DXP 7.4 U44+/Portal 7.4 GA44+
サーバーが一般公開される前にすべてのアップグレードが実行されるようにするため、2つのOSGiイベントが設けられています。
public String PORTAL_INITIALIZED =
"(module.service.lifecycle=portal.initialized)";
public String PORTLETS_INITIALIZED =
"(module.service.lifecycle=portlets.initialized)";
-
PORTAL_INITIALIZEDイベントがトリガーされると、コアアップグレードプロセスは既に実行されているはずであり、起動時にアップグレードするアプローチを使用している場合は、その時点で会社も初期化されているはずです。 -
モジュールのアップグレードは、
PORTAL_INITIALIZEDが登録されたときに開始され、PORTLETS_INITIALIZEDイベントがトリガーされたときに完了する必要があります。 その後、起動時にアップグレードを行う方式の場合のみ、サーバーはリクエストを受信できるようになります。
こうすることで、Liferayはサーバーが一般公開される前にすべてのアップグレードが実行されることを保証します。
これらの OSGi イベントに依存する場合は、コンポーネントに次の参照を追加してください。 こうすれば、そのイベントがトリガーされるまで利用できなくなります。
@Reference(target = ModuleServiceLifecycle.PORTAL_INITIALIZED)
private ModuleServiceLifecycle _moduleServiceLifecycle;