CoreData Entity "A" имеет отношение "один ко многим" к коллекции CoreData "В", используя правило Cascade delete.
В среде iCloud, в то время как устройство 1 показывает подробное представление одной из записей "B" , устройство 2 удаляет запись "A" .
Когда уведомление NSPersistentStoreDidImportUbiquitousContentChangesNotification принимается в устройстве 1, его делегат приложения вызывает mergeChangesFromContextDidSaveNotification, а затем транслирует внутреннее уведомление, которое захватывается контроллером представления, отображающим детали записи "B" (в коде используется performBlock где он должен).
Однако, хотя запись "A" действительно сбрасывается, когда контроллер подробного представления получает внутреннее уведомление, запись "B" все еще существует как действительный объект CoreData. Кажется, что правило Каскада еще не завершило свою работу. Поэтому контроллер вида в устройстве 1 не знает об удалении, что может привести к неожиданным результатам.
mergeChangesFromContextDidSaveNotification появляется преждевременно, когда базовые данные были объединены, но правило Cascade еще не завершено.
Я попытался обновить запись "B" , когда уведомление поступило, временно установив ноль stalenessInterval контекста управляемого объекта, чтобы кешированный объект не использовался, но я все еще получаю действительную запись "B" из магазин.
Проверка записи null "A" на данном этапе не является вариантом, потому что ситуация несколько сложнее, чем то, что я описал здесь, и в некоторых случаях допустимая допустимая ошибка "A" может быть действительной.
Я попытался ввести задержку после слияния изменений и перед отправкой внутреннего уведомления контроллерам представления. Я узнал, что 2-секундная задержка не помогает, но работает 10-секундная задержка.
Но я не хочу полагаться на эту задержку. Это тестовая среда без больших данных, и я не знаю, что произойдет в производственной среде. Опираясь на экспериментальную задержку, не кажется правильным.
Есть ли правильная вещь? Или я начинаю с чего-то не так?