2

设想：

我在 IOS 上使用配置为对 SQLite 数据库进行操作的 Magical 记录。默认情况下，MR 配置 coredata 将所有写回主线程上的父上下文序列化。

我使用的模式是，当我不在主线程上时，我使用诸如 MagicalRecord:MR_saveWithBlockAndWait 之类的东西为 coredata 操作创建一个单独的 NSManagedObjectContext。神奇的记录创建上下文，将其连接到父上下文，执行您在回调块中指定的任何操作并最终保存。重要的是，保存应该在操作完成之前提交。

当我完成后台线程的工作时，我通常会通知 UI 发生了一些事情；例如：某些内容已下载/上传/更改。

然后在 UI 线程上，我使用主线程上的默认上下文创建一个新的 fetch 请求。问题是偶尔 coredata 找不到我之前提交的新对象。问题表现在微妙的竞争条件下，如果 UI 线程由于动画或其他一切正常运行而稍微慢一些 - 但有时它找不到新对象。

从我读过的内容来看，获取请求总是应该去磁盘。MOC 上还有一个过时属性，但听起来这仅与缓存有关，如果您执行 fetch 请求，则会被绕过。

有没有人遇到过类似的问题并有任何见解？谢谢。

4

1 回答 1

1

当然。如果您在后台托管对象上下文中保存更改，但您的 UI 上下文已经加载了该对象，则 UI 上下文可能只是从其缓存而不是存储文件中为您提供数据。

使用多个上下文的常用方法是：

  1. 观察NSManagedObjectContextDidSaveNotification以便您知道后台上下文何时保存更改。

  2. 在此通知的处理程序中，调用mergeChangesFromContextDidSaveNotification:UI 上下文，以便它使用来自其他上下文的更改来更新自身。

您可能希望mergePolicy在您的 UI 上下文中设置 ，因为默认设置是在有任何冲突更改时放弃。

这适用于任何多上下文场景，其中每个上下文都需要使用不同上下文保存的更改进行更新。

于 2013-10-15T18:43:18.100 回答