“核心数据不能实现故障”。错误 [英] "Core Data could not fulfill a fault.." error

查看:136
本文介绍了“核心数据不能实现故障”。错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发可可应用程序。我面临一个关键的问题。

I am developing an application in cocoa. I am facing a critical problem.

我使用以下代码删除Core Data中名为Directory的对象的条目:

I am deleting entries of an object named "Directory" in Core Data using the following code:

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

但有时候例外情况是核心数据无法完成故障在删除后尝试保存时发生。我使用代码 [managedObjectContext save];

But sometimes an exception like "Core Data could not fulfill a fault.." occurs while trying to save after deletion. I am using the code [managedObjectContext save];

我是Core Data的新用户...期待一个解决方案。

I am new in Core Data... Looking forward to a solution.

推荐答案

这是一个老问题,我已经努力解决这一段时间了。

This is an old question, I have struggled resolving this for some time now. So, thought it would be best to document it.

正如Weichsel上面提到的, Apple文档正确指出了此异常的原因。但是,识别模块是一个忙碌的工作,因为NSManagedObject子类的对象被保留(如果文档中第一个引用的原因是问题的根本原因)。

As Weichsel above mentioned, the Apple documentation rightly points out reason for this exception. But it is a hectic job to identify the module due to which the NSManagedObject subclass' object is being retained (if 1st cited reason in the documentation is the root cause of the problem).

所以,我开始通过识别我的代码中保留NSManagedObject的部分,而不是保留NSManagedObjectID,并在需要时创建托管对象。类似行的讨论可以在Restkit文档中找到:

So, I started out by identifying the parts of my code which was retaining the NSManagedObject, instead I retained the NSManagedObjectID and create the managed object out of it whenever needed. The discussion in similar lines can be found in Restkit documentation:


  1. https://github.com/RestKit/RestKit/commit/170060549f44ee5a822ac3e93668dad3b396dc39

  2. https://github.com/RestKit/RestKit/issues/611#issuecomment-4858605

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

更新了我的setter和getter,使得与其余模块的接口保持不变,而在内部我们现在依赖于NSManagedObjectID,并避免保留NSManageObject: / p>

Updated my setter and getter so that the interface with rest of the modules remain same while internally we now depend upon NSManagedObjectID and avoid retaining of 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]];
    }
}

上面是问题的前半部分解决。我们需要找出在我们的应用程序的可疑部分的依赖,并消除。

The above is the first half of the problem solved. We need to find out dependency in suspicious parts of our app and eliminate.

还有一些其他问题,工具 - >分配是一个很好的来源,找出哪些模块实际上保留被管理对象,异常对象将具有关于哪个被管理对象正在创建问题的细节,过滤该对象的结果如下所示:

There was some other problem too, instruments -> allocations is a good source to find out which modules are actually retaining the managed objects, the exception object would have details about which managed object is creating the problem, filter results for that object as shown below:

我们在托管对象上执行KVO。 KVO保留观察到的托管对象,因此抛出异常,它的回溯不会来自我们的项目。这些都很难调试,但猜测工作和跟踪对象的分配和保留发布周期肯定会有帮助。我删除了KVO观察部分,它都开始工作。

We were performing KVO on a managed object. KVO retains the observed managed object and hence the exception is thrown and it's back trace would not be from within our project. These are very hard to debug but guess work and tracking the object's allocation and retain-release cycle will surely help. I removed the KVO observation part and it all started working.

这篇关于“核心数据不能实现故障”。错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆