【问题标题】:CoreData update problemsCoreData 更新问题
【发布时间】:2012-10-26 21:45:09
【问题描述】:

我的应用在后台线程中进行更新,然后保存上下文更改。 在主要上下文中,有一个与NSFetchedResultsController 一起使用的表格视图。 一段时间内更新正常工作,但随后引发异常。 为了检查这一点,我将NSLog(@"%@", [self.controller fetchedObjects]); 添加到-controllerDidChangeContent:。 这是我得到的:

"<PRBattle: 0x6d30530> (entity: PRBattle; id: 0x6d319d0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p2> ; data: {\n    battleId = \"-1\";\n    finishedAt = \"2012-11-06 11:37:36 +0000\";\n    opponent = \"0x6d2f730 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p1>\";\n    opponentScore = nil;\n    score = nil;\n    status = 4;\n})",
"<PRBattle: 0x6d306f0> (entity: PRBattle; id: 0x6d319f0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p1> ; data: {\n    battleId = \"-1\";\n    finishedAt = \"2012-11-06 11:37:36 +0000\";\n    opponent = \"0x6d2ddb0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p3>\";\n    opponentScore = nil;\n    score = nil;\n    status = 4;\n})",
"<PRBattle: 0x6d30830> (entity: PRBattle; id: 0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p11> ; data: <fault>)",
"<PRBattle: 0x6d306b0> (entity: PRBattle; id: 0x6d319e0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p5> ; data: {\n    battleId = 325;\n    finishedAt = nil;\n    opponent = \"0x6d2f730 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p1>\";\n    opponentScore = 91;\n    score = 59;\n    status = 3;\n})",
"<PRBattle: 0x6d30730> (entity: PRBattle; id: 0x6d31a00 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p6> ; data: {\n    battleId = 323;\n    finishedAt = nil;\n    opponent = \"0x6d2ddb0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p3>\";\n    opponentScore = 0;\n    score = 0;\n    status = 3;\n})",
"<PRBattle: 0x6d307b0> (entity: PRBattle; id: 0x6d31630 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p9> ; data: {\n    battleId = 370;\n    finishedAt = \"2012-11-06 14:24:14 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 180;\n    score = 180;\n    status = 4;\n})",
"<PRBattle: 0x6d307f0> (entity: PRBattle; id: 0x6d31640 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10> ; data: {\n    battleId = 309;\n    finishedAt = \"2012-11-02 01:19:27 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 120;\n    score = 240;\n    status = 4;\n})",
"<PRBattle: 0x6d30770> (entity: PRBattle; id: 0x6d31620 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p7> ; data: {\n    battleId = 315;\n    finishedAt = \"2012-11-02 02:26:24 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 119;\n    score = 179;\n    status = 4;\n})"

)

此处的故障对象 (0xe972610) 会导致崩溃。我在更新期间和保存之前记录了数据。此对象仅在 updatedObjects 中。为什么这个方法可以返回“坏”对象? (此外,在更新期间,该对象几乎每次更新都会受到影响。并且只有在某些通过之后才会变成“坏”)。

P.S.:我使用 RestKit 来管理 CoreData。

更新 2:

看起来问题出在[self.controller fetchedObjects] 枚举中。它是从- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller 调用的,并且似乎即使在此方法调用期间这些对象也会被修改(我的意思是CoreData 更新尚未完成)。有可能吗?

更新:

异常发生了,当我做某事的时候。像这样:

for (PRBattle *battle in [self.controller fetchedObjects) {
    switch (battle.statusScalar) {
        case ...
        default:
            [battle willAccessValueForKey:nil];
            NSAssert1(NO, @"Unexpected battle status found: %@", battle);
    }
}

例外是在线-willAccessValueForKey:。战斗的标量状态是枚举,即绑定到整数值 1..4。我已经提到了 switch 案例中的所有可能值(以上default:)。最后一个有break;。所以这个只有当battle.statusScalar返回非枚举值时才有可能。

PRBattle 中的状态标量实现:

- (PRBattleStatuses)statusScalar
{
    [self willAccessValueForKey:@"statusScalar"];
    PRBattleStatuses result = (PRBattleStatuses)[self.status integerValue];
    [self didAccessValueForKey:@"statusScalar"];
    return result;
}

battle.status 有验证规则: - 最小值:1 - 最大值:4 - 默认值:无值

最后一件事——调试日志:

objc[4664]: EXCEPTIONS: throwing 0x7d33f80 (object 0xe67d2a0, a _NSCoreDataException)
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b401 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b401 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: handling exception 0x7d33f60 at 0x97b79f
objc[4664]: EXCEPTIONS: rethrowing current exception
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b911 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b911 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: finishing handler
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b963 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b963 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x3656f sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: handling exception 0x7d33f60 at 0xa701f5
2012-11-07 13:37:55.463 TestApp[4664:fb03] CoreData: error: Serious application error.  An exception was caught from the delegate of NSFetchedResultsController during a call to -controllerDidChangeContent:.  CoreData could not fulfill a fault for '0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10>' with userInfo {
    NSAffectedObjectsErrorKey =     (
        "<PRBattle: 0x6d30830> (entity: PRBattle; id: 0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10> ; data: <fault>)"
    );
}

【问题讨论】:

  • 您是否为每个线程使用不同的 NSManagedObjectContext?在此链接stackoverflow.com/questions/2138252/… 上查看已接受的答案
  • 此外,你为什么说对象 0xe972610 会导致崩溃?如果您指的是“故障”一词,则意味着另一件事。一个错误是当一个对象没有完全加载到内存中时,只有当你尝试访问它时,它才会被核心数据透明地加载
  • 抛出异常时Core Data究竟输出了什么?
  • LombaX,感谢您的评论。但我已经阅读了所有这些并遵守了所有规则。而且我认为它导致崩溃不是错误,而是稍后使用这些对象 - 请参阅我的更新。汤米,谢谢你,也看看我的更新。
  • @kpower 我看到您正在使用 fetchedObjects 来访问所有获取的对象。是否有可能导致错误的对象在您的操作过程中已被其他线程删除?来自 fetchedObjects 方法的文档:结果数组反映了控制器托管对象上下文中托管对象的内存状态,而不是它们在持久存储中的状态。 但是,返回的数组不会随着托管对象的插入、修改或删除而更新。

标签: ios core-data restkit nsfetchedresultscontroller


【解决方案1】:

崩溃主要原因:“在后台线程中保存容易出错”(http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/CoreData/Articles/cdConcurrency.html//apple_ref /doc/uid/TP40003385-SW7)。当然,我以前读过这个。但是,RestKit 的问题变得更大了。它适用于“contextForCurrentThread”。因此,您应该获得后台线程的唯一上下文(根据同一文档)。但是你不能从主线程中保存它,除非你直接传递它,因为在主线程中这个方法返回另一个上下文。当我看到这个时,我认为 RestKit 为我解决了这个问题(在“正常”保存期间,而不是从主线程),但没有。

第二件事是NSFetchedResultsController。当你从-controllerDidChangeContent: 调用[self.controller fetchedObjects] 时,你应该准备好了,这个数组可以及时更改。我拿了这个数组并进行枚举,检索了必要的数据。并且在枚举过程中它被改变了(我认为,这是一个 NSMutableArray 返回到 NSArray 的机智类型转换 - 所以这种行为成为可能)。您永远不会在“默认”行为中看到这一点(当您为每个呈现的单元格获取带有 objectForIndexPath: 的对象时 - 如在 Apple 示例中),但在我的应用程序中,我有其他单元格,除了包含数据对象。所以我需要生成自己的存储,而不是直接使用控制器获取的结果。这样我会建议完全避免使用NSFetchedResultsController。我已经用简单的NSManagedObjectDidSaveNotification 观察者替换了它,并且每次都加载数据。

【讨论】:

  • “数组已更改”是什么意思? [self.controller fetchedObjects] 是一个 NSArray,所以它不会改变(意思是:不能添加或删除对象,所以计数会保持不变)。但是你必须记住数组的本质:对象的集合 --> 如果数组指向的对象之一改变了自身(想象指向一个从“a”变为“b”的 NSMutableString),“内容" 数组的变化,即使它是不可变的。所以问题是我建议的两个问题:-P 后台管理问题和 [self.controller fetchedObjects] ;-)
  • 这是一个错误:类似“枚举时更改了数组”。你错了,返回NSArray 的方法实际上可以简单地返回NSMutableArray(因为NSArray 是他的父母)。虽然所有其他人都会“认为”它是不可变的,但它是可以改变的。
  • 还有一件事。枚举对象时,可以毫无问题地更改它们的参数。因为指针不会改变 - 你永远不会在这里得到任何错误。
  • 但是您比其他人更接近结果解决方案 :) 所以谢谢您(以及所有提供建议的用户)!!
  • 关于您的第二条评论,这正是我所说的 :) 如果您有一个不可变数组,则对象的内容仍然可以更改。不变的是指向对象(它们的地址)的指针和它们的计数。所以我的问题是:发生了什么变化?对象的数量或其内容?我假设第二个 :-) --> 对象在核心数据堆栈中被更改/删除,但 fetchedObjects 数组仍然具有对该对象的引用!
猜你喜欢
  • 2015-09-04
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-06-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-06-07
相关资源
最近更新 更多