Ручка основных данных Выборка объекта, который No Longer не существует

Question

Справочной информации:

У меня есть приложение, которое получает доступ к учетной записи электронной почты пользователя и извлекает данные учетной записи: электронная почта, папка и т.д. Этот процесс включает в себя несколько этапов, последнее из который заключается в сохранении или обновлении вновь полученной информации до основных данных. Весь процесс от начала до конца может занять пару секунд.

Вот проблема:

1. Пользователь открывает приложение, извлечение новых или обновленных учетных данных начинается процесс.
2. Пользователь решает удалить текущую учетную запись, для которой происходит выборка.
3. Выполняется вызов для отмены любых открытых запросов на выборку для текущей учетной записи, однако запросы на выборку завершены, а основные данные теперь пытаются сохранить новые данные.
4. При попытке доступа к «существующим» объектам данных ядра для их обновления объекты удаляются и происходит сбой.

В частности, ошибка я получаю выглядит следующим образом:

CoreData: annotation: logically false fetch request <NSFetchRequest: 0x13ce1430> (entity:  Thread; predicate: (threadId == 1457719230395529203 AND folder == <Folder: 0xc1994c0> (entity: Folder; id: 0xc2ccb20 <x-coredata://A0837E88-30EB-46E8-A9BC-D6699EC7F160/Folder/p10> ; data: <fault>)); sortDescriptors: ((null)); type: NSManagedObjectResultType;) short circuits. 

И авария происходит на линии, где основные данные пытается извлечь объект, который больше не существует.

Будучи новым для основных данных, мне интересно, существует ли общая стратегия для обработки таких обстоятельств.

Answer 1

Вы можете отделить эту логическую работу от модели данных, чтобы каждая основная операция завершалась до того, как следующая запускается с использованием операций в очереди.

В этом конкретном случае это просто звучит так, будто отмена текущего запроса обрабатывается неправильно. Вы должны быть в состоянии остановить ожидающие операции после отмены действия. Возможно, вам придется добавить флаг и проверить, отменено ли действие после каждого асинхронного обратного вызова и до сохранения изменений.