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