コンテンツフラグメントモデル、永続クエリ、コンテンツパッケージ content-fragment-models-persisted-queries-and-content-packages

コンテンツフラグメントモデルと永続GraphQL クエリは、作成および更新できるコンテンツです。

  • コンテンツフラグメントモデル:/conf/<config>/settings/dam/cfm/models)
  • 永続的なGraphQL クエリ:(/conf/<config>/settings/graphql/persistentQueries)

多くのプロジェクトでは、それらをGitに保存し、コンテンツパッケージに出荷します。 このようなパッケージのフィルターモードによって、何が起こるかが決まります(オーサーで作成されたモデルとクエリを含む)。

  • mode="replace"

    • 各ノード:

      1. フィルターでカバー
      2. パッケージ内に含まれていません
      3. は作成時に削除され、Cloud Managerのデプロイメント中にパッケージがインストールされるたびに公開されます
    • モードが明示的に定義されていない場合のデフォルトのモードです。

この方法で削除されたモデルに依存する永続クエリは、Schema provider failedで失敗します。

ルートがパスをカバーする場合、FileVaultは最初のフィルターエントリを適用するので、フィルターエントリの順序は重要です。 /conf/<config>などの幅広いエントリは、より特定のエントリの前に配置する場合に優先されます。

モデルとクエリの所有者に応じた、推奨される設定:

  • Gitで管理:

    • モデルごとに1つのフィルタールート、またはパッケージが所有する永続的なクエリを、より広範な/conf エントリの前に配置します。
      作成者で作成されたコンテンツは影響を受けません。
    • より広範な範囲を持つconf個のエントリが存在する場合は、update_propertiesなどの非削除モードを使用するか、特定の作成者が所有するコンテンツを除外することができます。
  • 所有権の混在:

    • 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