我在使用子上下文作爲NSPrivateQueueConcurrencyType的便箋時遇到了問題。使用NSPrivateQueueConcurrencyType子上下文與NSPrivateQueueConcurrencyType父上下文
視圖控制器使用的主要背景。 Worker Context用於從API導入數據。我正在使用mergeChangesFromContextDidSaveNotification合併主和工作環境之間的更改。如果我將「工作者子女」背景排除在外,事情似乎正常運作。
但是,我想在導入對象時使用工作人員子上下文作爲便箋。一些數據需要構建嵌套對象,並且如果在構建過程的某個地方出現錯誤,我想只是拋棄該背景。如果構建成功,我希望能夠保存工作者子上下文,讓它將更改推送到工作者上下文中,然後可以將更改保存併合併到主上下文中。
但是,當我嘗試在Worker Child Context中執行獲取請求來執行查找或創建操作時,即使它在Worker Child Context的performBlock
內完成,我也得到了多線程斷言。
我不確定哪些代碼片段可以幫助回答這個問題,但我主要關心的是我的整體方法不起作用。有一個私人隊列上下文作爲另一個上下文的孩子是一個壞主意?
編輯:
我遇到的崩潰是當工人的孩子上下文將嘗試執行讀取請求做一個查找或創建操作。它沒有在謂詞中使用任何託管對象,並且其包裝在performBlockAndWait
中。我得到的解釋是'NSInternalInconsistencyException',原因是:'語句仍然處於活動狀態'崩潰是間歇性的,但到目前爲止,它似乎只發生在嵌套工作者子上下文時。 (即我的圖中的工作人員子上下文將擁有自己的創建對象的子上下文)
導致崩潰的提取請求始終用於查找或創建操作,因此它試圖獲取具有唯一標識符的任何對象屬性與正在導入的對象的標識符匹配。所以謂詞總是像"identifier in ["1234", "abc", "etc" ]
正如我在評論中提到的,我最初使用PSC-> Private Context-> Main Context-> Private Worker Context設置。我遇到UI凍結,而工作者上下文在導入數據時提取並保存,所以我試圖重構此堆棧以釋放UI。
你在做什麼導致多線程斷言的performBlock?這將提供關於發生了什麼問題的線索。 – Tim