以前のバージョンでのアップグレードプロセスの使用
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()メソッドを、データベースを変更するための指示でオーバーライドします。runSQLメソッドとrunSQLTemplate*メソッド (BaseDBProcessクラスから継承) を使用して、それぞれ SQL コマンドと SQL DDL を実行します。 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 を使用している場合は、 Bundle Activator を作成して登録し 、Liferay の
Release_テーブルに登録します。 -
UpgradeStepRegistratorサービス タイプUpgradeStepRegistrator.classの OSGi コンポーネント クラスを作成し、UpgradeStepRegistratorインターフェイスを実装します。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 { } -
レジスタメソッドをオーバーライドして、データベースをあるスキーマ バージョンから次のバージョンに更新するために必要なアップグレード手順に対するモジュールのアップグレード登録—抽象化を実装します。 たとえば、アップグレード ステップ レジストラ クラス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_テーブルに記録されます。 複数のパッケージで同じクラス名が使用されている場合は、以下のUpgradeFooクラスの 2 番目の登録 (1.0.0から1.1.0) に示すように、クラスの完全修飾クラス名を指定する必要があることに注意してください。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レジストレータ クラスは、UpgradePortletSettingsアップグレード ステップのSettingsFactoryクラスを参照します。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;