CoreData + iCloud + Cascade删除 - 如何处理？

Question

CoreDataCoreData使用级联删除规则,实体"A"与条目"B" 的集合具有一对多的关系.

在iCloud环境中,当设备1显示"B"条目之一的详细视图时,设备2删除"A"条目.

当NSPersistentStoreDidImportUbiquitousContentChangesNotification在设备1中接收到通知时,其App Delegate调用mergeChangesFromContextDidSaveNotification然后广播内部通知,该内部通知由视图控制器捕获,显示条目"B"的细节(代码使用performBlock它应该的位置).

但是,尽管当详细视图控制器接收到内部通知时,条目"A"确实无效,但条目"B"仍然作为有效CoreData对象存在.似乎Cascade规则尚未完成其运作.因此,设备1中的视图控制器不知道删除,这可能导致意外的结果.

mergeChangesFromContextDidSaveNotification 当基础数据已合并但Cascade规则尚未完成时,似乎过早地返回.

我在通知到达时尝试刷新条目"B",同时暂时将stalenessInterval托管对象上下文设置为零,因此不会使用缓存对象,但我仍然从商店获得有效条目"B".

此时检查null条目"A"不是一个选项,因为情况比我在此描述的情况稍微复杂一些,并且空条目"A"在某些情况下可能有效.

我尝试在合并更改之后和将内部通知发送到视图控制器之前引入延迟.我发现2秒延迟没有帮助,但延迟10秒有效.

但我不想依赖这种延迟.这是一个没有太多数据的测试环境,我不知道在生产环境中会发生什么.依靠实验性延迟似乎不是正确的做法.

有没有正确的事情？或者我开始做错了什么？

Answer 1

根据经验，收听除此之外的通知NSManagedObjectContextDidSaveNotification会造成很大的混乱，并可能导致依赖尚未更新的属性。详细视图控制器应该监听NSManagedObjectContextDidSaveNotification应用级联后抛出的通知。然后，您可以通过多种方式检查当前对象是否有效（您可以检查当前对象的托管对象上下文是否有效，nil或者可以执行提取并查看该对象是否存在于存储中）。