内容片段模型、持久查询和内容包 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中维护：
- 每个模型拥有一个筛选器根或包拥有的持久查询，放在更广泛的
/conf条目之前。
则为作者创建的内容不会受到影响。 - 如果存在范围更广的
conf条目，您可以确保这些条目使用非删除模式（如update_properties），或仅排除特定作者拥有的内容。
- 每个模型拥有一个筛选器根或包拥有的持久查询，放在更广泛的
-
混合所有权：
-
mode="update_properties"：添加和更新，但从不删除。取舍是在Git中删除的模型或字段会保留在AEM中。
-
-
由作者拥有：
-
不要将其包含在包中，或仅使用
mode="merge_properties"为其播种一次合并不适用于在Git中维护的模型，因为现有节点保持不变，并且永远不会部署模型更改。 FileVault还弃用了合并和更新，支持
merge_properties和update_properties。
-
有关在Git中维护两个模型并允许作者创建其他模型的项目的示例：
<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"/>
experience-manager-cloud-service-help-main-toc