設定エンティティはEntity APIを使用して、設定をデータベースに保存します。
Content Entityとの違い
- エクスポートを可能にするためCMI APIと統合されています
- フィールドはありません
- スキーマファイル（Content Entityはhook_schema()を使用）
チュートリアル
Drupal 8では、バンドル（bundles）は情報のコンテナタイプであり、フィールドの定義や設定を保存します。「サブタイプ」と呼ばれることもあります。バンドルはオプションであり、情報コンテナの階層でエンティティタイプの下に位置します。
- エンティティのバリエーション（コンテンツと設定。多くのエンティティはペアで存在します。例：ブロック）
- エンティティタイプ
- バンドルまたはサブタイプ（オプション）
これらのコンテナタイプの例：
汎用エンティティのAPIメソッドを扱います
- Entity::create()
- Entity::load()
- Entity::save()
- Entity::id()
- Entity::bundle()
- Entity::isNew()
- Entity::label()
より具体的なAPIは、特定の章で説明します。
- Drupal 7 - Entityは汎用のstdClassオブジェクトでした。
- Drupal 8 - Entityは現在、特定の型付けを持つオブジェクトになりました。各エンティティタイプは、そのエンティティのインスタンスに使用されるクラスを定義します。
要件
Entityクラスは、エンティティタイプを提供するモジュールのEntity名前空間サブスペースに配置する必要があります。例：\Drupal\[module_name]\Entity。つまり、EntityクラスのPHPファイルはモジュールのsrc/Entityディレクトリにあります。
クラスのdocblockには、そのタイプのEntityのメタデータを定義するEntityTypeアノテーションが含まれている必要があります。これには、エンティティタイプのラベル、コントローラー、テーブルなどが含まれます。利用可能なすべてのメタデータプロパティの文書化されたリストについては、\Drupal\Core\Entity\Annotation\EntityTypeクラスを参照してください。
Drupal 8のエンティティシステム
エンティティはメソッドを持つ型付きクラスです
| Generic methods |
$entity->id() |
| Entity type specific methods | $node->getTitle() |
Background
Entity SystemはDrupal 7の開発サイクルの終盤に、基本的なエンティティ読み込み標準とともに導入されました。追加されたentity.moduleはAPIをさらに拡張し、エンティティの保存・削除のサポートや、その他多くの改善を追加しました。
Drupalのデータベースレイヤーは、SQL関数のデータベース横断的な抽象化を提供しません。サポートされているデータベースエンジン間での移植性を確保するには、ANSI標準の一部であり、Drupalがサポートするすべてのデータベースでサポートされていることがわかっている関数のみを使用する必要があります。以下はまだ不完全なリストです。ここで使用される形式が推奨されます。他の構文のバリエーションはすべてのデータベースで動作しない可能性があるためです。
データベースレイヤーには演算子のホワイトリストがないことに注意してください。したがって、REPLACE()などの非標準関数を渡しても、その構文をサポートするデータベースでは動作します。
論理演算子
- AND
- OR
- NOT
比較演算子
- <
- >
- <=
- >=
- <>
- LIKE
Database APIはエラー時に例外を生成します。この例のように、データベース操作をtry {} catch() {}ブロックで囲むことで例外をキャッチできます：
// ここでトランザクションが開始されます。
$txn = $connection->startTransaction();
try {
$id = $connection->insert('example')
->fields([
'field1' => 'mystring',
'field2' => 5,
])
->execute();
my_other_function($id);
return $id;
}
catch (Exception $e) {
// 問題が発生したため、トランザクションをロールバックします。
$txn->rollBack();
// 例外をwatchdogに記録します。
\Drupal::logger('type')->error($e->getMessage());
}
Drupalは、トランザクションをサポートしないデータベース向けの透過的なフォールバックを含め、トランザクションもサポートしています。ただし、2つのトランザクションを同時に実行しようとすると、トランザクションはかなり複雑になる可能性があります。この場合の動作もデータベースに依存します。
同様の問題は、C/C++のネストされたロックにも存在します。コードが既にロックAを取得していて、再びロックAを取得しようとすると、コードはブロックされます。既にロックを持っているかどうかをチェックし、再取得を試みないコードを書けば、デッドロックを回避できますが、ロックを時期尚早に解放する可能性があります。
SQLにも同じ問題があります。コードが既にトランザクション内にある場合、新しいトランザクションを開始すると、現在のトランザクションをコミットして新しいトランザクションを開始するという、予期しない残念な結果が生じます。
削除クエリは常にクエリビルダーオブジェクトを使用する必要があります。delete()メソッドを使用して次のように開始します：
$query = $connection->delete('mytable', $options);これにより、mytableテーブルからレコードを削除する削除クエリオブジェクトが作成されます。テーブル名に中括弧は不要です。クエリビルダーが自動的に処理するためです。
削除クエリオブジェクトは流れるようなAPIを使用します。つまり、execute()を除くすべてのメソッドがクエリオブジェクト自体を返すため、メソッド呼び出しを連結できます。多くの場合、これはクエリオブジェクトを変数に保存する必要がまったくないことを意味します。
削除クエリは概念的に非常にシンプルで、WHERE句のみで構成されます。WHERE句の完全な構造は「条件句」セクションで詳しく説明されており、ここでは簡単に触れるだけです。
完全な削除クエリは次の形式になります：
マージクエリは特殊なタイプのハイブリッドクエリです。構文はSQL 2003仕様で定義されていますが、標準構文をサポートするデータベースはほとんどありません。ただし、ほとんどのデータベースは、データベース固有の構文を使用した代替実装を提供しています。Drupalのマージクエリビルダーは、マージクエリの概念を構造化オブジェクトに抽象化し、各データベースに適した構文でコンパイルできるようにします。これらは、UPDATEとINSERTの組み合わせである「UPSERT」クエリと呼ばれることもあります。
一般的には、マージクエリは挿入クエリと更新クエリの組み合わせです。指定された条件が満たされた場合、たとえば指定された主キーを持つ行が既に存在する場合は、更新クエリが実行されます。存在しない場合は、挿入クエリが実行されます。最も一般的なケースでは、これは次と同等です：