All geek questions in one place

Problems updating CoreData

My application makes updates in the background thread and then saves the context changes. And in the main context there is a table view that works with NSFetchedResultsController . For some time the updates work correctly, but then an exception is thrown. To test this, I added NSLog(@"%@", [self.controller fetchedObjects]); in -controllerDidChangeContent: Here is what I got:

 "<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})"

)

A faulty object (0xe972610) causes a failure here. I logged data during the update and before saving. This object is only in updatedObjects . Why can this method return a “bad” object? (In addition, during updates this object affects almost every update. And only after some passes become "bad").

PS: I use RestKit to control CoreData.

UPDATE2:

It seems like the problem is listing [self.controller fetchedObjects] . It is called from - (void)controllerDidChangeContent:(NSFetchedResultsController *)controller and it seems that these objects are modified even during this method call (I mean that the CoreData update was not completed to this point). Is it possible?

UPDATED:

An exception was received when I did smth. eg:

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

The exception is the line with -willAccessValueForKey: The scalar state for a battle is an enumeration, that is, a binding to integer values ​​1..4. I mentioned all the possible values ​​in switch cases (above default: . And the latter has a break; . Thus, this is only possible when battle.statusScalar returns a value without an enumeration.

Scalar state implementation in PRBattle :

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

And battle.status has validation rules: - minimum value: 1 - maximum value: 4 - default: no value

And last: debug log:

 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>)" ); }
+4
source share
1 answer

The main reason for the failure: "Saving in the background thread is due to an error" (http://developer.apple.com/library/ios/#documentation/ cocoa / conceptual / CoreData / Articles / cdConcurrency.html // apple_ref / DOC / UID / TP40003385-SW7). Of course I read this before. But the problem remained in RestKit. It works with "contextForCurrentThread". This way you get the only context for the background thread, as it should be (according to the same document). But you cannot save it from the main thread, unless you pass it directly, in the main thread this method returns a different context. When I saw this, I thought that RestKit fixed it for me (during the "normal" save, and not from the main thread), but no.

Secondly, NSFetchedResultsController . When you call [self.controller fetchedObjects] from -controllerDidChangeContent: you must be prepared so that this array can be changed over time. I took this array and, making an enumeration, extracted the necessary data. And during the listing it was changed (I think this a NSMutableArray returned the wity trait to NSArray - so it becomes possible). You will never see this in the "default" behavior (when you get objects with objectForIndexPath: for each displayed cell - as in Apple's examples), but in my application I have additional cells besides containing data objects. So I need to create my own repository, and not directly get the results from the controller. And so I recommend not using NSFetchedResultsController at all. I replaced it with a simple NSManagedObjectDidSaveNotification observer and loading data every time.

0
source

Source: https://habr.com/ru/post/1444463/

More articles:


All Articles