在更新NSFetchedResultsControllers之前,Core Data是否实际保存对磁盘的任何更改? [英] Does Core Data actually save any changes to disk before updating NSFetchedResultsControllers?

查看:165
本文介绍了在更新NSFetchedResultsControllers之前,Core Data是否实际保存对磁盘的任何更改?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是一个非常具体的问题,我刚刚被咬了,为了节省别人一些时间和痛苦,这里是我的问题深入和解决方案。

This is a very specific question and I've been bitten by it just now, so to save others some time and agony, here's my problem in-depth and the solution.

例如,保存主上下文时,它会触发NSFetchedResultsController委托回调,您可以依赖于保存实际已完成的事实,并且您可以在这些回调中安全地执行新的获取请求,假设当前保存数据将包括在内?

When you save the main context, for instance, and it triggers NSFetchedResultsController delegate callbacks, can you depend upon the fact that your save has actually completed, and could you safely perform new fetch requests within those callbacks assuming that the currently saved data will be included?

答案是否。

推荐答案

如果您的应用程序中有活动的NSFetchedResultsController(NSFRC),它们具有委托集并且正在监视对相关对象的更改,那么这里有一个小的未记录的警告,所有Core Data开发人员应该注意。如果对主上下文执行保存,并且NSFRC在主上下文上工作,则在主上下文上调用 save:将实际更新NSFRC,并调用 willChangeContent:.. didChangeContent:.. 等回调您的NSFRC委托,然后才真正将MOC内容保存到磁盘。

If you have active NSFetchedResultsController's (NSFRC) in your app that have a delegate set and are monitoring changes to relevant objects, then here's a small undocumented caveat that all Core Data developers should be aware of. If you perform a save on the main context, and have NSFRC's working on the main context, then calling save: on the main context will actually update the NSFRC first and call the willChangeContent:.., didChangeContent:.., etc. callbacks on your NSFRC delegate before actually saving the MOC contents to disk.

这可能有问题的原因是,如果您尝试使用 NSDictionaryResultType 的resultType执行新的获取请求> 在这些NSFRC回调内,那么您的抓取请求将不会包含任何当前更改。根据当前的变化,我的意思是这些变化,你的NSFRC回调被调用的第一。

The reason why this could be problematic is if you try to execute a new fetch request using a resultType of NSDictionaryResultType inside those NSFRC callbacks, then your fetch request won't include any current changes. By current changes, I mean those changes for which your NSFRC callbacks were called in the first place.

你不会看到这些变化的原因是因为设置resultType到 NSDictionaryResultType 关闭 includesPendingChanges 属性。因此,获取请求只能直接从磁盘获取更改,并且不会合并上下文中的任何本地更改。

The reason why you won't see those changes is because setting the resultType to NSDictionaryResultType turns off the includesPendingChanges property. So the fetch request only gets changes directly from the disk and doesn't merge any local changes from the context.

我可以理解为什么使用字典结果类型的任意获取请求不会合并上下文中未保存的结果的原因,因为字典可以有任意的结构,而MOC在图中建模对象和关系,然而,对我来说有趣和令人惊讶的部分是NSFRC委托在实际执行保存之前获得更新回调。

I can somewhat understand the reasons why arbitrary fetch requests using a dictionary result type don't merge unsaved results from the context since the dictionaries could have any arbitrary structure, while the MOC is modeling objects and relationships in a graph, however, the part that was interesting and surprising to me was that the NSFRC delegate got update callbacks before a save was actually done.

这里是一些ASCII艺术:

Here's some ASCII art:


    1. save Main MOC --> | 2. NSFRC callbacks --> | 3. actual save happens here
                         |          |             |            
                         |          |             |
                         |          ▼             |
                         | NSDictionaryResultType |
                         | fetch requests won't   |
                         | see any changes from   |
                         | this current save, but |
                         | regular fetch requests |
                         | will see those changes |



PS:Core Data是一个在有限性能设备上运行的对象图管理框架。有时候你必须优化。

PS: Core Data is an object-graph management framework that runs on limited performance devices. Sometimes you gotta optimize.

这篇关于在更新NSFetchedResultsControllers之前,Core Data是否实际保存对磁盘的任何更改?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆