场景:
我在 IOS 上使用配置为针对 SQLite 数据库操作的 Magical 记录。默认情况下，MR 配置 coredata 将所有写回主线程上的父上下文序列化。
我使用的模式是，当我不在主线程上时，我使用诸如 MagicalRecord:MR_saveWithBlockAndWait 之类的东西为 coredata 操作创建一个单独的 NSManagedObjectContext。神奇的记录创建上下文，将其连接到父上下文，执行您在回调 block 中指定的任何操作并最终保存。重要的是，保存应该在操作完成之前提交。
当我完成后台线程的工作时，我通常会通知 UI 发生了一些事情；例如:某些内容已下载/上传/更改。
然后，在 UI 线程上，我使用主线程上的默认上下文创建一个新的 fetch 请求。问题是偶尔 coredata 找不到我之前提交的新对象。问题表现在微妙的竞争条件下，如果 UI 线程由于动画或其他一切正常运行而略微缓慢 - 但有时它找不到新对象。
从我读过的内容来看，获取请求总是应该进入磁盘。 MOC 上还有一个过时属性，但听起来这仅与缓存有关，如果您执行 fetch 请求，则会被绕过。
有没有人遇到过类似的问题并有什么见解？谢谢。
当然。如果您在后台托管对象上下文中保存更改，但您的 UI 上下文已经加载了该对象，则 UI 上下文可能只是从其缓存而不是存储文件中为您提供数据。
使用多个上下文的常用方法是:
观察 NSManagedObjectContextDidSaveNotification 以便您知道后台上下文何时保存更改。
在此通知的处理程序中，在 UI 上下文中调用 mergeChangesFromContextDidSaveNotification:，以便它使用来自其他上下文的更改来更新自身。
您可能希望在您的 UI 上下文中设置 mergePolicy，因为默认设置是在有任何冲突更改时放弃。
这适用于任何多上下文场景，其中每个上下文都需要使用不同上下文保存的更改进行更新。
关于ios - Coredata fetch 不返回刚刚写入存储的结果，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19380145/
| 欢迎光临 OStack程序员社区-中国程序员成长平台 (https://ostack.cn/) | Powered by Discuz! X3.4 |