У меня есть табличное представление, в котором отображается множество объектов, поэтому их выборка может занять некоторое время. NSAsynchronousFetchRequest кажется идеальным для этого, потому что он не блокирует основной поток, но я получаю NSManagedObject экземпляров, зарегистрированных в моем основном контексте очереди.
Пока выполняется запрос на выборку, в таблице отображается результаты основаны на массиве из предыдущей выборки. Это может потребовать обхода отношений, которые являются ошибками. Целевые объекты могли быть удалены с момента последней выборки. Использование shouldDeleteInaccessibleFaults может предотвратить исключения, но нежелательно проверять везде, чтобы убедиться, что объект не был удален. Я не хочу непреднамеренно использовать обнуленное свойство. Закрепление контекста с помощью setQueryGenerationFrom(_:) кажется хорошим решением. Это позволяет запускать сбои для объектов, которые были удалены из хранилища , но еще не из текущего контекста , и получать значения их свойств до удаления (за исключением случаев использования allowsExternalBinaryDataStorage).
Проблема в том, что кажется, что эти две функции на самом деле не работают вместе. Если я оставляю контекст закрепленным перед запуском асинхронной выборки, он (что неудивительно) извлекает старые данные, которые нельзя использовать для обновления таблицы. Но если я изменю генерацию запроса на .current перед запуском asyn c fetch, таблица больше не сможет запускать ошибки старого поколения, пока выполняется выборка; он увидит удаления слишком рано. Похоже, что в запросе asyn c fetch должна быть опция для установки генерации запроса выборки, которая немедленно повлияет на выборку, но не повлияет на другие операции в контексте, пока выборка не будет выполнена. Но, насколько я могу судить, этого нет, и поэтому основной контекст очереди по существу нарушается на время выборки.
Есть ли способ сделать асинхронные c выборки и генерации запросов работать вместе? Конечно, я мог бы выполнить обычную выборку в другом контексте, но это было бы менее эффективно и потребовало бы большего количества кода, потому что мне потребовался бы отдельный шаг для преобразования результатов в управляемые объекты в контексте основной очереди. И эти объекты могли измениться в магазине между выборкой и преобразованием. Я не хочу сильно изобретать NSAsynchronousFetchRequest.