CoreData + iCloud +级联删除 – 如何处理？
CoreData实体“A”使用级联删除规则与CoreData条目“B”的集合具有一对多关系。
在iCloud环境中，当设备1显示“B”条目之一的详细视图时，设备2删除“A”条目。
当设备1接收到NSPersistentStoreDidImportUbiquitousContentChangesNotification通知时，其App Delegate调用mergeChangesFromContextDidSaveNotification ，然后广播由视图控制器捕获的内部通知，显示条目“B”的细节（代码使用performBlock ）。
但是，尽pipe在详细视图控制器接收到内部通知时入口“A”确实无效，但条目“B”仍然作为有效的CoreData对象存在。 看来级联规则还没有完成。 因此，设备1中的视图控制器不知道删除，这可能会导致意外的结果。
mergeChangesFromContextDidSaveNotification出现提前返回，当基础数据已合并，但级联规则尚未完成。
当通知到达时，我尝试刷新条目“B”，同时暂时将pipe理对象上下文的stalenessInterval设置为零，以便caching的对象不会被使用，但是我仍然从商店获得有效的条目“B”。
在这一点上检查null条目“A”不是一个选项，因为情况比我在这里描述的要复杂一些，在某些情况下空条目“A”是有效的。
我试图在合并更改之后并在将内部通知发送到视图控制器之前引入延迟。 我发现延迟2秒没有帮助，但延迟10秒。
但我不想依赖这个延迟。 这是一个没有太多数据的testing环境，我不知道在生产环境中会发生什么。 依靠实验性延迟似乎不是正确的做法。
有没有正确的事情？ 还是我做错了，开始？
根据经验，侦听NSManagedObjectContextDidSaveNotification以外的通知是一个大混乱，并可能导致依赖尚未更新的属性。 详细信息视图控制器应该侦听NSManagedObjectContextDidSaveNotification通知，这些通知是在应用级联之后引发的。 您可以通过多种方法检查当前对象是否有效（您可以检查当前对象的托pipe对象上下文是否nil或者您可以执行提取并查看对象是否存在于该存储中）。
