CoreData countForFetchRequest говорит, что «сущность не найдена» - PullRequest
3 голосов
/ 23 октября 2009

При попытке подсчитать объекты в контексте управляемого объекта возникает странная проблема.

- (NSUInteger)countEntity:(NSString *)entityName 
                inContext:(NSManagedObjectContext *)context{

    NSFetchRequest *request = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription entityForName:entityName                     
                                                  inManagedObjectContext:context];
    [request setEntity:entity];
    [request setIncludesSubentities:NO];
    NSError *error = nil;
    NSUInteger count = [context countForFetchRequest:request error:&error];
    [request release];
    return count;
}

Линия:

NSUInteger count = [context countForFetchRequest:request error:&error];

бросает NSInternalInconsistencyException reason: 'entity not found'

Изменение на:

NSUInteger count = [[context executeFetchRequest:request error:&error] count];

работает без проблем.

Я в недоумении. Есть идеи?

Спасибо!

/ Oskar

Ответы [ 6 ]

4 голосов
/ 06 ноября 2009

Бегу к этому сегодня. Началось, когда я представил второй постоянный магазин. У вас есть более одного магазина в МЦ? * 1001 Кен *

1 голос
/ 11 февраля 2014

Для чего бы это ни стоило, я только что натолкнулся на похожую ошибку, в которой executeFetchRequest:error и countForFetchRequest:error: не согласовывают количество объектов в запросе на выборку.

Сценарий: я вложил NSManagedObjectContexts с корневым контекстом типа NSPrivateQueueConcurrencyType (для сохранения на диск), поддерживаемым постоянным хранилищем, и потомком этого типа NSMainQueueConcurrencyType (для использования графическим интерфейсом). (Да, я использую MagicalRecord)

У меня есть ViewController прослушивание NSManagedObjectContextDidSaveNotification из «основного» контекста. Когда это уведомление запускается, метод countForFetchRequest:error: не включает изменения, сделанные в контексте, которые не были сохранены в родительском корневом контексте. executeFetchRequest:error однако возвращает ожидаемый набор объектов.

Немного странно.

0 голосов
/ 24 октября 2009

Я запустил ваш метод countEntity: в одном из моих собственных проектов он работал нормально. Единственный способ заставить его выдать исключение («_countWithNoChangesForRequest: error: запрос на выборку должен иметь сущность.») - это когда я неправильно прописал название сущности (виджеты вместо виджетов). Итак, вы можете исследовать это направление.

0 голосов
/ 23 октября 2009

Я подозреваю, что entity равно nil (т. Е. context равно нулю или не имеет правильно настроенного координатора постоянного хранилища с моделью управляемого объекта, содержащей вашу сущность, или вы неправильно указали имя сущности где-то в объектемодель или в коде вызова).Убедитесь, что entity не является nil после вызова +[NSEntityDescription entityForName:inManagedObjectContext:].

0 голосов
/ 23 октября 2009

Проблема, с которой вы столкнулись из-за неправильного использования countForFetchRequest: error :. Действительно, в своем фрагменте кода вы сначала выполняете запрос на выборку, используя executeFetchRequest: error, затем переходите к использованию countForFetchRequest: error:.

Из документации по методу:

Возвращает количество объектов, которые вернул бы данный запрос на выборку, если бы он был передан executeFetchRequest: error:.

Поэтому вы НЕ должны выполнять запрос на выборку перед вызовом countForFetchRequest: error:.

0 голосов
/ 23 октября 2009

Проверьте несколько вещей:

  1. Какое значение error после первого звонка? Причина, по которой вы передаете этот объект, состоит в том, чтобы извлекать из него информацию, когда что-то идет не так.
  2. Какое значение [request entity] после первого звонка? Может быть, я полностью отключен, но я очень смутно помню кое-что о том, что запрос является одноразовой сделкой: как только вы выполните его, вам придется сбросить все различные поля, прежде чем вы сможете выполнить его снова. Убедитесь, что все свойства вашего запроса остаются действительными после первого вызова, или, что еще лучше, создайте второй экземпляр NSFetchRequest для выполнения второго вызова.
  3. В том же духе, что произойдет, если вы прокомментируете первый вызов? Если вы меняете порядок звонков? Результат одного может повлиять на другого.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...