abort fetchRequest в managedObjectContext

Question

У меня есть fetchRequest, который занимает до 4-5 секунд, чтобы закончить. Поскольку это часть решения типа «поиск по типу», существует ли способ прервать fetchRequest?

Я использую таймер, чтобы начать поиск в моей базе данных через 600 мс после окончания ввода пользователем. Таким образом, существует вероятность, что новый поиск начнется до того, как старое закончится.

Я не нашел методов для NSMangedObjectContext, которые кажутся правильными. Просто устанавливает старый fetchRequest = nil путь? Или еще что-то происходит на заднем плане?

Любые идеи?

Заранее спасибо!

PS: Я также пытаюсь повысить скорость моего запроса. Возможно, у кого-то есть идея для этого: https://stackoverflow.com/questions/4695729/query-performance-with-large-database

Answer 1

Лучший способ - это ограничение места для объектов запроса выборки.

• (пустоты) setFetchLimit: (NSUInteger) ограничивают Параметры предел выборки предел приемника. 0 не задает ограничение на выборку. Обсуждение

Особые соображения Если установить предел выборки, структура делает все возможное, но не гарантирует того, чтобы повысить эффективность работы. Для каждого хранилища объектов, за исключением хранилища SQL, запрос на выборку, выполненный с лимитом выборки, просто выполняет неограниченную выборку и выбрасывает незашифрованные строки.

Answer 2

Предполагая, что вы используете UITextField для ввода текста, почему бы вам не переместить логику fetchRequest на метод делегирования textField:shouldChangeCharactersInRange:replacementString: (UITextField)?

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

Answer 3

Я не думаю, что вы можете, так как он почти наверняка связывает нить, делающую выборку. В прошлый раз, когда мне нужно было сделать что-то подобное, я породил фоновый поток с базовым condvar (NSCondition), чтобы сигнализировать, когда новый вход был доступен, и -performSelectorOnMainThread:..., чтобы сигнализировать, когда выход был готов. Это означает, что фоновый поток будет продолжать работать на устаревших входах некоторое время, прежде чем поднять новый «самый последний» вход.

Возможно, вы можете сделать аналогичную вещь с NSOperation/NSOperationQueue, отменив все операции в очереди (представляющие старые входы) перед добавлением нового (представляющего самый последний ввод).

Поскольку NSMO/NSMOC не является потокобезопасным, вы, скорее всего, захотите передать набор (первых нескольких) MOID.