«Core Data не смог выполнить ошибку ..» ошибка

голоса
6

Я занимаюсь разработкой приложений в какао. Я столкнулся с критической проблемой.

Я удаление записей объекта с именем «Каталог» в основных данных, используя следующий код:

NSEnumerator *tempDirectories = [[folderArrayController arrangedObjects] objectEnumerator];
id tempDirectory;
while (tempDirectory = [tempDirectories nextObject]){
    [managedObjectContext deleteObject:tempDirectory];
}

Но иногда исключение, как «Core Data не смог выполнить ошибку ..» происходит при попытке сохранить после удаления. Я использую код[managedObjectContext save];

Я новичок в Core Data ... Заглядывая вперед к решению.

Задан 12/08/2009 в 10:17
источник пользователем
На других языках...                            


1 ответов

голоса
4

Это старый вопрос, я боролся решением этого в течение некоторого времени. Так, думал, что это будет лучше документировать его.

Как упоминалось выше Weichsel, документация Apple , справедливо указывает причину этого исключения. Но это неспокойная работа для идентификации модуля , благодаря которому объекту подкласса NSManagedObject в настоящее время удерживаемый (если первый цитируются причиной в документации является основной причиной проблемы).

Итак, я начал с определением части моего кода, который был удерживающая NSManagedObject, вместо этого я сохранил NSManagedObjectID и создать управляемый объект из него по мере необходимости. Обсуждение в подобных линиях можно найти в Restkit документации:

  1. https://github.com/RestKit/RestKit/commit/170060549f44ee5a822ac3e93668dad3b396dc39
  2. https://github.com/RestKit/RestKit/issues/611#issuecomment-4858605

Обновленные мой и присваиватель, чтобы интерфейс с остальными модулями остается таким же, а внутренне мы теперь зависим от NSManagedObjectID и избежать удерживающих от NSManageObject:

-(CSTaskAbstract*)task
{
    CSTaskAbstract *theTask = nil;
    if (self.taskObjectID)
    {
        NSManagedObjectContext *moc = [(CSAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
        // https://github.com/RestKit/RestKit/commit/170060549f44ee5a822ac3e93668dad3b396dc39 &
        // https://github.com/RestKit/RestKit/issues/611#issuecomment-4858605
        NSError *theError = nil;
        NSManagedObject *theObject = [moc existingObjectWithID:self.taskObjectID
                                                         error:&theError];
        if ([theObject isKindOfClass:[CSTaskAbstract class]])
        {
            theTask = (CSTaskAbstract*)theObject;
        }
    }
    return theTask;
}
-(void)setTask:(CSTaskAbstract *)inTask
{
    if (inTask!=self.task)
    {
        // Consequences of retaining a MO when it is detached from its MOC
        [self setTaskObjectID:[inTask objectID]];
    }
}

Выше первая половина решаемой задачи. Нам нужно выяснить зависимость в подозрительных частях нашего приложения и устранить.

Был какой-то другая проблема тоже, инструменты -> распределение является хорошим источником, чтобы узнать, какие модули фактически сохранив управляемые объекты, объект исключения будет иметь сведения о которых управляемый объект создает проблемы, результаты фильтрации для этого объекта, как показано ниже :

Инструменты - Отчисления

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

Ответил 29/10/2013 в 09:57
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more