內容片段模型、持續查詢和內容套件 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