Content entityとConfig entityをUMLで書いてみたら発見があったで、そもそもDrupalの中身ってどうなっているんだっけと整理し直したくなったので、日本語版で10.0.4をプレーンインストールして、Config Entityのymlファイルをエクスポートして眺めてみた。
ファイル数は192。
例えば、node.type.page.ymlのような形で、基本ページのコンテンツタイプのConfigurationが定義されている。
uuid: 10947a1e-6621-4f1a-af79-e877afb368f0
langcode: ja
status: true
dependencies: { }
_core:
default_config_hash: KuyA4NHPXcmKAjRtwa0vQc2ZcyrUJy6IlS2TAyMNRbc
name: 基本ページ
type: page
description: '「About us」のような、あまり更新されない内容の場合は <em>基本ページ</em> を使ってください。'
help: ''
new_revision: true
preview_mode: 1
display_submitted: false
このnodeにあたる接頭語の個数は28。
automated_cron 1ファイル
block 23
block_content 1
claro 1
comment 2
contact 4
core 40
dblog 1
editor 2
field 16 (内 field.storage 7)
field_ui 1
file 1
filter 5
image 5
language 7
locale 1
menu_ui 1
node 3
olivero 1
search 3
shortcut 1
system 41
taxonomy 2
text 1
tour 6
update 1
user 7
views 15
field.storage.node.body.yml
field.storage.node.comment.yml
field.storage.node.field_image.yml
field.storage.node.field_tags.yml
といった構成定義は、mysqlのテーブルに対応していてテーブル名はnode__bodyなどとなる。基本ページ(page)にも記事(article)にも本文(body)フィールドはあるが、データベース上はコンテンツタイプに関わらずnode__bodyに入る。
UMLでモデリングする時にあまり細かく書きすぎてしまうと可読性が落ちてしまうので、192のConfig Entityを記述する気にはならないが、Acquiaサイトビルダー試験に合格できるレベルを超えたら、一度眺めておく価値はあると思った。
例えば、field.field.node.article.body.ymlを読むと、field.storage.node.bodyとnode.type.articleに依存していて、型定義がtextモジュールで実装されていて、field_nameがbodyになっていることが分かる。
uuid: 5d8dfec9-44eb-4e21-9323-d336a25c0442
langcode: ja
status: true
dependencies:
config:
- field.storage.node.body
- node.type.article
module:
- text
_core:
default_config_hash: IjZnOLWk1Pjq3WRg2pLSA1ERh7Po7izCq_p6UztZr2c
id: node.article.body
field_name: body
entity_type: node
bundle: article
label: 本文
description: ''
required: false
translatable: true
default_value: { }
default_value_callback: ''
settings:
display_summary: true
required_summary: false
field_type: text_with_summary
mysqlでconfigテーブルを眺めていると192行で、ymlファイルの数と合致する。
初心者の頃は、コンテンツタイプ(node)の単位でテーブルが作られるのではないかと想像していたのだが、実際にはデータの中身はフィールド単位でテーブルができている。
基本ページコンテンツタイプでタイトルをテスト、本文を本文でコンテンツを作ると、nodeテーブルにうuuid、node_field_dataテーブルにタイトル、node__bodyテーブルに本文レコードが追加される。node_revisionにもレコードが追加される。このあたりまで見るとRDBにある程度の知識があれば仕組み(Content entityの保管方法)がどうなっているかが分かる。各テーブルにlangcodeカラムがあり、node_field_dataテーブルにはdefault_langcode=1が記録されている。CMSとしての世界観が見えてきて興味深い。
| bundle | deleted | entity_id | revision_id | langcode | delta | body_value | body_summary | body_format |
| page | 0 | 1 | 1 | ja | 0 | <p>本文</p> | basic_html |
元がWeb CMSだから、body_valueにhtmlタグが含まれているのはしょうがないし、当然とも言えるのだが、プレーンテキストと使い分ける必要性が見えてくる。
もちろん、最初は中身がどうなっているか考える必要など無いのだが、読んでみると発見がある。例えば、configテーブルはcollection、name、dataカラムしかなくリビジョン管理の機構が実装されていない。恐らく、将来はConfig entityにもリビジョン管理が導入されるだろうが、現時点ではその機能がないことを意識しておかないといけないのが分かる。
教科書的な書籍を書くためには、中身の理解が不可欠だ。まずは、データモデル、スキーマを理解した上で、プログラムやAPIを理解していくのが私の流儀だ。