CoreData实体“A”与CoreData条目“B”的集合具有一对多的关系，使用级联删除规则。
在iCloud环境中，当设备1显示其中一个“B”条目的详细视图时，设备2会删除“A”条目。
当在设备1中收到NSPersistentStoreDidImportUbiquitousContentChangesNotification通知时，其App Delegate调用mergeChangesFromContextDidSaveNotification，然后广播内部通知，该通知由视图控制器捕获，显示条目“B”的详细信息（代码使用performBlock应该在哪里。
但是，虽然当详细视图控制器收到内部通知时，条目“A”确实无效，但条目“B”仍然作为有效的CoreData对象存在。似乎Cascade规则尚未完成其运作。因此，设备1中的视图控制器不知道删除，这可能会导致意外结果。
mergeChangesFromContextDidSaveNotification似乎过早返回。
我尝试在通知到达时刷新条目“B”，同时临时将托管对象上下文的stalenessInterval设置为零，这样就不会使用缓存对象，但我仍然得到一个有效的条目“B “来自商店。
此时检查null条目“A”不是一个选项，因为情况比我在此描述的情况稍微复杂一些，并且在某些情况下空条目“A”可能有效。 / p>
我尝试在合并更改之后和将内部通知发送到视图控制器之前引入延迟。我发现2秒延迟没有帮助，但延迟10秒。
但我不想依赖这种延迟。这是一个没有太多数据的测试环境，我不知道在生产环境中会发生什么。依靠实验性延迟似乎不正确。
有没有正确的事情？或者我开始做错了什么？
答案 0 :(得分：1)
根据经验，收听NSManagedObjectContextDidSaveNotification以外的通知是一个很大的混乱，可能导致依赖尚未更新的属性。详细视图控制器应该监听NSManagedObjectContextDidSaveNotification通知，这些通知在应用级联后会引发。然后，您可以通过多种方式检查当前对象是否有效（您可以检查当前对象的托管对象上下文是否为nil，或者您可以执行提取并查看对象是否存在在商店里。）