このエントリはMagento Advent Calendar 2018の7日目です。

今回はMagento2.3で新たに導入されたDeclarative Schemaについて解説したいと思います。
なお、このエントリを読まれる前に、私がさくらのナレッジで執筆している記事をお読みいただくと、理解がしやすいかと思います。

Declarative Schemaとは

Declarative Schemaは、Magento2.2までのPHPコードを使用したデータベーススキーマ定義作成を置き換える仕組みです。
Magento2.3から新たに導入された仕組みで、XMLファイルを使用してテーブルの構造などを定義します。

Magento2.2までのテーブル定義の方法

これまではPHPコードでテーブル定義を行ってきたのですが、InstallSchema.phpで定義したテーブルに対してUpgradeSchema.phpで定義変更をかける流れになっていました。
このやり方はMagento1の実装方法に近く、Magentoに慣れた開発者にとっては理解しやすいものでした。とはいえ実際のところはMagentoのバージョンをアップデートする際に以下のようなムダが生じていました。

  • UpgradeSchema.phpが毎回のアップデート時に実行される。
  • UpgradeSchema.php単体にはMagento1のようなバージョン別定義がなく、見通しが悪くなりやすい。

Declarative Schemaが導入されたことによって、これらの問題が解消され、エクステンションのアップデート時にアップデート前のテーブル定義とアップデート後のテーブル定義を比較して、必要な変更を適用できるようになりました。
また、同時に導入されたData PatchやSchema Patchによって、XMLでは表現しづらい定義や、初期データの投入・更新をきちんとバージョン管理できるようになりました。

Declarative Schemaに対応するテーブル定義の作成

Declarative Schemaが使えるMagento2.3以降では、新しい設定ファイル「db_schema.xml」がテーブル定義に使用できます。
このファイルは、

エクステンションベンダー名/エクステンション名/etc/db_schema.xml

に配置する決まりになっています。
XMLファイルのタグ定義については公式DevDocsに詳しく書かれていますので、そちらをみていただくと良いでしょう。

Declarative Schemaを用いると、XML上に存在しない要素が追加された場合はその要素を定義し、なくなれば削除します。
Gitの利用が前提となっている現在のMagentoでは、XMLの変更履歴をGitのコミットログから追えば簡単に調べられるため、変更箇所がわかりやすくなったと言えるでしょう。

テーブルをリネームしたい場合

Magento2.3.0時点ではテーブルのリネームはサポートされていません。
公式DevDocsによると、テーブルを削除して新しい名前で作り直すことは可能で、テーブルの削除時に、該当テーブルに存在したデータをCSVで残すことは可能です。
ただし、作り直したテーブルに自動的にデータが取り込まれることはないので、別途取り込み処理をData Patchなどで作成する必要があります。

列をリネームしたい場合

列をリネームしたい場合、XML上の定義を変更することになりますが、公式DevDocsにもある通り、onCreate属性を用いて古い列や参照先のテーブルの列から値をセットすることが可能です。

Magento2.2までの方式は使えなくなる？

当面の互換性維持として、Magento2.2までの方式も引き続き利用できます。
ただし、いつまでとはMagentoは明言していないので、どこかのメジャーバージョンアップで廃止する可能性は大いにありえます。

まとめ

Magento2.3で導入されたDeclarative Schemaは、従来のPHPスクリプトによるデータベース定義管理を置き換えるものです。
今回はdb_schema.xmlについてだけを取り上げましたが、実際はData PatchやSchema PatchといったXMLでは定義・処理が難しい操作を行う機能が用意されています。

次回はData PatchとSchema Patchを使ったMagento2.3以降の管理方法について解説したいと思います。