NSManagedObjectContext save метод throws exception

Question

Я просмотрел все сообщения, которые сообщают о проблемах с managedObjectContext save: Но я не нашел ничего, что, казалось бы, решило проблему, которую я вижу. У большинства из них проблемы с координацией FRC с помощью tableView. Это другое.

Проблема возникает, когда я вызываю save в экземпляре NSManagedObjectContext. Захват и протоколирование чтения исключений: «невозможно выполнить оценку коллекции с помощью объекта, не связанного с сборкой». Кто-нибудь знает, что это может означать?

@try { 
     if ([self.managedObjectContext hasChanges]) { 
      @synchronized(managedObjectContext) { 
       if(![managedObjectContext save:&error]) { 
        NSLog(@"\n\n---------UNRESOLVED ERROR--------------\n\n UserInfo: \n%@, %@", error, [error userInfo]); 
        [self.managedObjectContext rollback]; 
       } 
      } 
     } 
    } 
    @catch (NSException *exception) { 
     NSLog(@"\n\n---------UNRESOLVED ERROR--------------\n\n exception: \n%@\n%@", exception, error); 
    } 

Единственный ключ, который у меня есть, - это повторяемость этой проблемы. Это происходит после того, как я зачеркнул мой сохраненный fetchedResultsController accessor, а затем создаст новый экземпляр с набором предикатов.

 if(searchFetchedResultsController) { 
      self.searchFetchedResultsController = nil; 
     } 

     self.searchFetchedResultsController = [predicateBuilder createSearchInContext:managedObjectContext forDelegate:self withSortDescriptors:self.sortDescriptors forEntityName:@"Record"]; 

     NSError *error = nil; 
     [self.searchFetchedResultsController performFetch:&error]; 

     if(error) 
      NSLog(@"\nfetch error: %@", error); 

я позже сохранить новый NSFetchedResultsController без каких-либо предикатов, используя обычную конструкцию аксессора.

 if(fetchedResultsController) { 
      self.fetchedResultsController = nil; 
     } 

     NSError *error = nil; 
     if (![self.fetchedResultsController performFetch:&error]) { 
      NSLog(@"Unresolved error %@, %@", error, [error userInfo]); 
      abort(); 
     } 

Я позже добавлю запись managedObject; спасти; и запустить в исключение, заброшенное путем сохранения.

Что интересно, это происходит каждый раз и только тогда, когда мои предикаты запрашивают числа или даты. Он делает не возникает при запросе строк. Итак, я понял, что построение запроса, похоже, является единственной разницей. Дело в том, что оба создают достоверные предикаты (через SUBQUERY), потому что выборка не прерывается. Итак, если есть разница, я не могу сказать вам, что это может быть.

Другие вещи, которые стоит отметить, есть каждое место, которое я «Alloc» КОП это выглядит следующим образом:

[[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:managedObjectContext sectionNameKeyPath:nil cacheName:nil]; 

Обратите внимание на ноль cacheName и sectionNameKeyPath

Я использую два указателя прояснить мое основывается FRC с неиспользуемым FRC. Я знаю, что это кому-то будет, если я не буду упоминать об этом.

-(void) setSearchFilteredNames:(BOOL)boolValue { 
    searchFilteredNames = boolValue; 
    if(boolValue) { 
     self.searchFetchedResultsController.delegate = self; 
     self.fetchedResultsController.delegate = nil; 
     //self.fetchedResultsController = nil; //lazy regeneration 
    } else { 
     self.searchFetchedResultsController.delegate = nil; 
     //self.searchFetchedResultsController = nil; //lazy regeneration 
     self.fetchedResultsController.delegate = self; 
    } 
} 

Кроме того, когда я поймаю исключение, новый объект сохраняется.

Answer 1

Я предполагаю, что я работал слишком поздно ...

Из того, что я понимаю, что это плохая практика, чтобы использовать подзапрос для заполнения NSPredicates, когда нет к-многим в ключевом пути к атрибуту интереса модель данных.

Это было действительно запутанно, потому что поиск все равно выполнялся и возвращал результаты, которые я ожидал. Только после того, как я добавил новый управляемый объект с FRC, который не имел никакого отношения к моему предикату SUBQUERY, что проблема проявилась.

Я надеюсь, что это поможет кому-то ...