【发布时间】：2012-05-20 10:35:36
【问题描述】：
CoreData 实体“A”与CoreData 条目“B”的集合具有一对多关系，使用级联删除规则。
在iCloud 环境中，当设备 1 显示“B”条目之一的详细视图时，设备 2 删除“A”条目。
当设备 1 收到NSPersistentStoreDidImportUbiquitousContentChangesNotification 通知时，它的 App Delegate 调用mergeChangesFromContextDidSaveNotification，然后广播一个内部通知，该通知由视图控制器捕获，显示条目“B”的详细信息（代码使用performBlock它应该在哪里）。
然而，虽然在详细视图控制器收到内部通知时条目“A”确实无效，但条目“B”仍然作为有效的CoreData 对象存在。级联规则似乎还没有完成它的操作。因此设备 1 中的视图控制器不知道删除，这可能会导致意外结果。
mergeChangesFromContextDidSaveNotification 似乎过早返回，当基础数据已合并但级联规则尚未完成时。
我尝试在通知到达时刷新条目“B”，同时将托管对象上下文的stalenessInterval 临时设置为零，因此不会使用缓存的对象，但我仍然从商店。
此时检查null 条目“A”不是一种选择，因为情况比我在这里描述的要复杂一些，并且在某些情况下空条目“A”可能是有效的。
我尝试在合并更改之后和将内部通知发送到视图控制器之前引入延迟。我发现 2 秒延迟没有帮助，但 10 秒延迟有效。
但我不想依赖这种延迟。这是一个没有太多数据的测试环境，不知道生产环境会发生什么。依赖实验性延迟似乎不是正确的做法。
有正确的事情吗？还是我一开始就做错了什么？
【问题讨论】：
-
它比看起来的要多，因为级联删除会在哪个先出现时立即传播：processPendingChanges、保存或运行循环周期的结束。在正常情况下，您描述的问题不应该存在。
-
是 NSPersistentStoreDidImportUbiquitousContentChangesNotification 附带的 NSDeletedObjectsKey 数组中详细视图控制器中对象的托管对象 ID？
-
这种情况总是发生还是间歇性发生？我有一个复杂的层次结构，还没有看到任何孤儿！您是否再次获取实体 B，或者可能是因为您以某种方式显示它，您保留了对该对象的引用。如果您关闭应用程序并重新打开它，实体 B 仍然存在会发生什么？
-
@Amiram 一年半。你得到你的答案了吗？ :)
标签： ios core-data icloud cascading-deletes