匹配CoreData保存通知回调

我想挑选某人的大脑。我有一个专门的保存NSManagedObjectContext和我从中操作的GCD队列。每当新数据进入我的应用程序时，我将其保存在该上下文中并将更改合并到主上下文中。我的问题在于告诉主线程刚刚发生了什么。我打电话后立即保存我的当前上下文现在是最新的，但如果我在主要上下文中触发一个方法，它的上下文不是。如果我等待NSManagedObjectContextDidSave通知，并且我保存了三次，我现在有三个排队的委托电话，但没办法将它们与进入的通知相匹配。有谁知道解决此问题的好方法吗？匹配CoreData保存通知回调

编辑

我最终什么事做的是创造每个保存操作一个新的背景和附加块时保存通知到达被调用。它看起来像这样，http://pastie.org/2068084

来源

2011-06-14 axiixc

从哪里得到NSManagedObjectContext实例？ – 2011-06-14 16:51:57

我为主线程创建了一个全局上下文，用作只读上下文，而且我有一个处理新数据的单例，因此它有自己的写上下文。 – axiixc 2011-06-14 18:31:51

我不确定你是什么意思，“...如果我在主要上下文中触发一个方法，它的上下文不是，如果我等待NSManagedObjectContextDidSave ...”意味着你不会等到上下文合并为止。如果是这样，那就是为什么你不能访问数据，它只是不在前面的上下文中。

你以后收到该通知从前面上下文打电话mergeChangesFromContextDidSaveNotification:？

来源

2011-06-14 16:59:40 TechZen

它是一个计时问题。在[上下文保存]返回后，我通常会在主线程（具有自己的上下文）上调用委托方法，但是委托调用在NSNotification需要合并更改之前到达，所以我最终没有新数据进行刷新在主线程上，然后在更改中进行合并。 – axiixc 2011-06-14 18:36:04

我不知道你是如何能够领先通知的，因为它是发送给save方法本身的。这对我来说听起来就像你必须紧密结合操作。你真的不应该从后台调用前线程/操作的方法。您应该依靠通知在前景和背景之间进行通信。 – TechZen 2011-06-14 20:40:57

从你对我上面评论的回答中，我发现你在通知中传递了managedObjectContext。我没那么有信心异步的东西，但我不认为你侵犯了一些并发的规则，如果我正确地解释从NSManagedObjectContext Class Reference这句话：

并发核心数据使用线程（或序列化队列）限制来保护托管对象和托管对象上下文（请参阅“与核心数据并发”）。其结果是上下文假定默认所有者是分配它的线程或队列 - 这由调用其init方法的线程决定。因此，您不应该在一个线程上初始化上下文，然后将其传递给另一个线程。相反，您应该传递对持久存储协调器的引用，并让接收线程/队列创建一个从此派生的新上下文。

我想说，尝试传递通知中的持久存储协调器，并在该块中重新创建托管对象上下文。

来源

2011-06-14 21:02:32

这对线程安全性来说很好，因为通知是从它们发送的线程到达的。此通知也生成并发送CoreData框架，所以我相信它是安全的。 – axiixc 2011-06-15 02:42:53

匹配CoreData保存通知回调

回答

相关问题