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