使用 Core Data 合并从一个上下文到另一个上下文的更改答案

【问题标题】：Merging changes from one context to another with Core Data使用 Core Data 合并从一个上下文到另一个上下文的更改
【发布时间】：2012-06-30 11:59:29
【问题描述】：

我对 iOS 5 的并发选项有点困惑。通常，使用旧方法，您必须使用 mergeChanges 和通知手动跟踪从一个上下文到另一个上下文的更改。但是，如果我的理解是正确的，那么使用新选项，您可以拥有一个带有子上下文的 NSMainQueueConcurrencyType。因此，每当您保存子上下文时，更改都会自动向上推送并与父上下文合并，而无需任何其他手动操作，对吗？

如果是这样，我遇到了问题。假设我有一个由主上下文获取的对象。然后我更改了这些对象的一些属性，但我还没有保存。然后，在父设置为 mainContext 的 NSPrivateQueueConcurrencyType 上，我执行 fetch 以检索我刚刚在主上下文中修改的对象。获取的对象会反映我刚刚在主线程上对属性所做的更改吗？

【问题讨论】：

标签： iphone ios core-data

【解决方案1】：

获取的对象会反映我刚刚在主线程上对属性所做的更改吗？

没有。在您 -refreshObject:mergeChanges:YES 之前，这些更改不会反映在子上下文中。

作为思考的食物，UIManagedDocument 以相反的方式执行此操作。它为主线程创建一个子上下文，并使用 NSPrivateQueueConcurrencyType 作为父线程的上下文。现在在主线程上进行的所有更新都将自动传播到父上下文。所以当文档在后台保存时，所有的更改都会在那里。

【讨论】：

为什么这家伙说要让context知道把对象变成fault来释放内存就可以了？ stackoverflow.com/a/3984681/458960
您使用 -refreshObject:mergeChanges:NO 来修剪对象图。那就是你明确地告诉你要放弃你在当前上下文中对对象所做的任何更改。
等等我在哪里调用 refreshObject？在父线程（待更改的位置）还是在子线程？
在您的示例中，您在对父上下文进行更改后在子上下文中调用它。