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