Ensembles文檔設計

我在一年前購買了Ensembles支持，但可悲的是現在只能嘗試使用它。Ensembles文檔設計

我有一個支持多個核心數據文檔的應用程序，並試圖確定發現它們的最佳方法。在你的書中，你建議使用自定義註冊表來支持plist文件的文檔元數據可能是實現文檔發現，名稱更改等的最佳方式。我設計了一種方法來實現這一點，但是意識到一旦我去「更新「（通過使用相同的文件名進行更改並上傳到雲）文件的plist文件我收到錯誤：

2017-07-26 10：54：16.986553-0700 XXX [6080：2429554]由於現有項目，某些記錄無法上傳。通常由於CloudKit上的過時查詢緩存。會自我糾正。忽略：defaultOwner）=

這讓我意識到它與設計中的另一個問題相矛盾......文件並不意味着被刪除並重新上傳，因爲這樣就存在競爭條件，最終可能會導致數據損壞。

是否有一種特定的方式，您認爲plist文件可以更新，以便您可以信任其中的數據，或者您應該上傳帶有時間戳名稱的新plist文件，並「希望」數據已正確合併。

您能否詳細介紹一下您的設計理論，以瞭解如何用Ensembles解決文檔註冊的問題？

謝謝海梅

來源

2017-07-26 J. S.

其實是有一種方法來檢測，而無需使用像這樣的屬性列表或任何存在哪些文件。 CDEPersistentStoreEnsemble上有一個叫做+retrieveEnsembleIdentifiersFromCloudFileSystem:completion:的類功能。

https://github.com/drewmccormack/ensembles/blob/master/Framework/Source/Ensemble/CDEPersistentStoreEnsemble.h#L392

這將通過完成處理程序返回合奏標識符的陣列。如果您將您的合唱團與您的文檔文件名稱相同，則應該能夠找出雲數據中存在的內容，而無需同步plists或類似的東西。

來源

2017-07-30 09:19:27

嗨德魯，我想我應該明確表示，我確實想維護一個plist來爲特定文檔提供一個動態標識符。推理是要跟蹤商店是否必須被刪除，並因此移動到另一個標識符或遷移到另一個核心數據模型版本。還有其他一些原因，但這些是最大的。考慮到這一要求，當信息需要更新時，如何建議維護這樣的註冊表，從而必須對文件進行更改。您在書中暗示了這一點，但沒有說明應該如何實施。 –

我仍然認爲你應該使用我提到的方法來獲取雲文檔，並使用該信息更新每個設備上的本地plist。即不同步plist。這樣，您可以看到刪除等。請注意，您可以通過在合併的完成塊中的CDEPersistentStoreEnsemble的nonCriticalErrorCodes屬性中查找CDEErrorCodeUnknownModelVersion來檢測由於模型更改而導致的錯誤。 –

Ensembles文檔設計

回答

相關問題