EF Core Azure Cosmos DB プロバイダーの制限事項

Azure Cosmos DB データベース プロバイダーは、ドキュメント データベースである Azure Cosmos DB NoSQL ストアを対象としています。 ほとんどの EF Core プロバイダーは、リレーショナル データベースを対象としています。 ドキュメント データベースとリレーショナル データベースは、基本的に異なる方法で動作します。 EF Core はこれらの違いを隠そうとはしません。むしろ、EF Core は、両方の種類のデータベースで正常に使用できる共通パターンと、特定の種類のデータベースのベスト プラクティスに従う特定のプロバイダーに合わせた機能を提供します。 EF Core の機能が特定の種類のデータベースにとって失敗の落とし穴 (pit-of-failure) となる場合、通常、データベース プロバイダーはその機能を実装せず、代わりに成功の落とし穴 (pit-of-success) アプローチにユーザーを誘導します。

ドキュメント データベースを使用する場合、適用されない、または失敗の原因となる一般的な EF Core パターンは以下のとおりです。

• ドキュメントに対して定義されたスキーマがないため、スキーマの移行がサポートされていません。 ただし、Azure Cosmos DB NoSQL に適した、進化するデータ シェイプを処理するための他のメカニズムが存在する可能性もあります。たとえば、 Cosmos DB のスキーマ バージョン管理パターンや Azure Cosmos データ移行などです。
• 既存のデータベースからのモデルのリバース エンジニアリング (スキャフォールディング) はサポートされていません。 繰り返しになりますが、スキャフォールディングの対象となるデータベース スキーマが定義されていないため、これはサポートされていません。 ただし、「Azure Cosmos DB データベースのドキュメントのシェイプを使用してスキーマをスキャフォールディングする」をご覧ください。
• ドキュメント データベースを使用する場合、スキーマが存在しないため、インデックスや制約などの EF モデルで定義されたスキーマ概念は無視されます。 Azure Cosmos DB NoSQL はドキュメントのインデックスを自動的に作成する点に注意してください。
• 異なるドキュメントからの関連エンティティのグラフの読み込みは、サポートされていません。 ドキュメント データベースは、多数のドキュメント間で結合を実行するようには設計されていません。これを行うと、かなり効率が下がります。 代わりに、必要なものがすべて 1 つまたは少数のドキュメントに含まれるよう、データを非正規化する方が一般的です。 ただし、処理できるドキュメント間のリレーションシップには形式がいくつかあります。「Azure Cosmos DB の限定的な Include のサポートをご覧ください。

警告

EF プロバイダーが使用する Azure Cosmos DB SDK では、同期 I/O はサポートされていません。 その結果、ToList や SaveChanges などの同期 EF API はバージョン 9.0 以降でスローされます。EF を使用する場合は、常に非同期メソッドを使用します。 EF の以前のバージョンでは、返された Task で .Wait() を呼び出すことによって同期 API をサポートしていました。これは「非同期での同期」と呼ばれ、デッドロックにつながる可能性があるため、まったく推奨されない手法です。 詳しくは、EF 9.0 の破壊的変更に関するメモをご覧ください。

リレーショナル データベースとドキュメント データベースの違いや SDK の制限に加え、Azure Cosmos DB NoSQL の EF Core プロバイダーには、EF Core と Azure Cosmos DB SDK の組み合わせを使用して実装 できる すべての機能が含まれているわけではありません。 この分野での潜在的な機能強化は、ラベルの付いた EF Core GitHub リポジトリの問題によって追跡されます。area-cosmos 問題の重要性を示す最良の方法は、それに投票 (👍) することです。 このデータが、次のリリースの計画プロセスに取り込まれます。