在具有共享持久存储的 NSManagedObjectContexts 之间复制挂起的更改？答案

【问题标题】：Copying pending changes between NSManagedObjectContexts with shared persistent store?在具有共享持久存储的 NSManagedObjectContexts 之间复制挂起的更改？
【发布时间】：2012-03-15 21:25:31
【问题描述】：

我有两个NSManagedObjectContext 实例：一个用于主线程，另一个用于后台线程（通过NSOperation。）为了线程安全，这两个上下文只共享一个NSPersistentStoreCoordinator。

我遇到的问题是第一个上下文（在主线程上）中的未决更改在执行-save 之前无法用于第二个上下文。这是可以理解的，因为共享持久存储不会保留被-insertedObjects、-updatedObjects 和-deletedObjects 跟踪的NSManagedObjects 的副本。

不幸的是，这给用户体验带来了问题：任何未保存的更改都不会出现在后台线程中生成的（耗时）报告中。

我能想到的唯一解决方案是讨厌：从第一个上下文中获取插入、更新和删除的对象，并将它们移植到第二个上下文的对象图上。数据集中有一些相当复杂的关系，所以我很犹豫要不要朝这个方向走。我希望这里有人能提供更好的解决方案。

【问题讨论】：

标签： objective-c core-data nsmanagedobject nsmanagedobjectcontext nsoperation

【解决方案1】：

如果这是 10.7 以下，有一些解决方案：一种是您可以嵌套 ManagedObjectContexts，因此您可以“保存”在正在修改的那个中，它不会一直保存到磁盘，但它会使主上下文的其他子级可用的更改。

在 10.7 之前，您可能必须自己复制更改。这并不难，因为您可以让一个对象监听NSManagedObjectContextObjectsDidChangeNotification，然后只需从主上下文中重新应用更改即可。（应该是大约 20 行代码。）你永远不必保存我假设的第二个上下文？

【讨论】：

谢谢威尔！我希望以 10.6 为目标，尽管每天都变得越来越难 :-) -- 我已经在跟踪更改通知，但我不确定您如何重新应用更改并维护实体关系。能具体一点吗？
啊，是的。我根据我的模型无形地做出了一个假设，即每个对象都有一个你自己维护的 UUID（字符串）键。
如果没有在后台 MOC 中保存，插入内容对主 MOC 不可见（没有嵌套的 MOC）。如果您收听更改通知（在 processPendingChanges 之后发出）并自己更新对象，则现有对象的更新/删除应该可以工作。

【解决方案2】：

不确定您是否有任何操作系统限制，但在 iOS 5 / Mac OS 10.7 中，您可以使用嵌套托管对象上下文来完成此操作。我相信子上下文能够通过简单地进行新的获取来获取父上下文中未保存的更改。

编辑： 看起来 Wil 打败了我，但是是的，在 iOS 5 / Mac OS 10.7 之前，您必须收听 NSManagedObjectContextDidSaveNotification 并查看 userInfo 字典以了解添加的内容/更新/删除的对象。

【讨论】：

【解决方案3】：

另一种解决方案可能涉及使用单个托管对象上下文并在访问它时提供您自己的线程安全，或者使用上下文的锁定和解锁方法。

【讨论】：

【解决方案4】：

我会尝试让主线程进行正常保存，以便第二个上下文可以将更改合并到他的上下文中。 “战斗” API 的预期用途绝不是一个好主意。如果用户最终取消编辑，您可以使用属性将新保存的记录标记为中间记录并在以后删除。

使用实体中的属性解决这些问题并在后台线程中使用匹配的谓词进行查询会很容易......

这也是一个稳定的解决方案。我来自数据库驱动的世界（oracle），我们经常使用这样的模式（记录中的状态属性）来使数据对其他数据库会话可见/不可见（这相当于可可应用程序中的线程）。工作总是没有问题。其他线程/会话总是只看到大多数 RDBMS 工作方式所提交的更改。

【讨论】：