コンテンツフラグメントモデル、永続クエリ、コンテンツパッケージ content-fragment-models-persisted-queries-and-content-packages
コンテンツフラグメントモデルと永続GraphQL クエリは、作成および更新できるコンテンツです。
- コンテンツフラグメントモデル:
/conf/<config>/settings/dam/cfm/models) - 永続的なGraphQL クエリ:
(/conf/<config>/settings/graphql/persistentQueries)
多くのプロジェクトでは、それらをGitに保存し、コンテンツパッケージに出荷します。 このようなパッケージのフィルターモードによって、何が起こるかが決まります(オーサーで作成されたモデルとクエリを含む)。
-
mode="replace"-
各ノード:
- フィルターでカバー
- パッケージ内に含まれていません
- は作成時に削除され、Cloud Managerのデプロイメント中にパッケージがインストールされるたびに公開されます
-
モードが明示的に定義されていない場合のデフォルトのモードです。
-
この方法で削除されたモデルに依存する永続クエリは、Schema provider failedで失敗します。
ルートがパスをカバーする場合、FileVaultは最初のフィルターエントリを適用するので、フィルターエントリの順序は重要です。 /conf/<config>などの幅広いエントリは、より特定のエントリの前に配置する場合に優先されます。
モデルとクエリの所有者に応じた、推奨される設定:
-
Gitで管理:
- モデルごとに1つのフィルタールート、またはパッケージが所有する永続的なクエリを、より広範な
/confエントリの前に配置します。
作成者で作成されたコンテンツは影響を受けません。 - より広範な範囲を持つ
conf個のエントリが存在する場合は、update_propertiesなどの非削除モードを使用するか、特定の作成者が所有するコンテンツを除外することができます。
- モデルごとに1つのフィルタールート、またはパッケージが所有する永続的なクエリを、より広範な
-
所有権の混在:
-
mode="update_properties":追加と更新は行われますが、削除はありません。トレードオフは、Gitで削除されたモデルまたはフィールドがAEMに残ることです。
-
-
作成者による所有:
-
パッケージに含めたり、
mode="merge_properties"で1回だけシードしたりしないでくださいMergeは、既存のノードが変更されないままになり、モデルの変更がデプロイされないため、Gitで維持されているモデルには適していません。 FileVaultでは、結合と更新も非推奨となり、
merge_propertiesとupdate_propertiesが優先されました。
-
Gitで2つのモデルを管理し、作成者が他のモデルを作成できるプロジェクトの例:
<filter root="/conf/wknd/settings/dam/cfm/models/article"/>
<filter root="/conf/wknd/settings/dam/cfm/models/author"/>
<filter root="/conf/wknd" mode="update_properties"/>
その他のリソース further-resources
関連トピック:
recommendation-more-help
experience-manager-cloud-service-help-main-toc