CoreData实体“A”与条目“B”的集合具有一对多关系CoreData，使用级联删除规则。
在一个iCloud环境中，当设备 1 显示“B”条目之一的详细视图时，设备 2 删除“A”条目。
当NSPersistentStoreDidImportUbiquitousContentChangesNotification设备 1 收到通知时，它的 App Delegate 调用mergeChangesFromContextDidSaveNotification然后广播一个内部通知，该通知由视图控制器捕获，显示条目“B”的详细信息（代码使用performBlock它应该使用的位置）。
然而，虽然在详细视图控制器收到内部通知时条目“A”确实无效，但条目“B”仍然作为有效CoreData对象存在。级联规则似乎还没有完成它的操作。因此设备 1 中的视图控制器不知道删除，这可能会导致意外结果。
mergeChangesFromContextDidSaveNotification当基础数据已合并但级联规则尚未完成时，似乎过早返回。
我尝试在通知到达时刷新条目“B”，同时stalenessInterval将托管对象上下文的临时设置为零，因此不会使用缓存的对象，但我仍然从商店获得有效的条目“B”。
此时检查null条目“A”不是一种选择，因为情况比我在此处描述的要复杂一些，并且在某些情况下空条目“A”可能是有效的。
我试图在合并更改之后和将内部通知发送到视图控制器之前引入延迟。我发现 2 秒延迟无济于事，但 10 秒延迟有效。
但我不想依赖这种延迟。这是一个没有太多数据的测试环境，不知道生产环境会发生什么。依赖实验性延迟似乎不是正确的做法。
有正确的事情吗？还是我一开始做错了什么？