问题
I am having difficulty with an NSFetchedResultsController which is returning 0 sections the first time I run my app but the correct number of sections when I close and reload the app subsequently.
I have noticed that if I NSLog the array[[self.fetchedResultsController fetchedObjects] description], I get a slightly different result between the first and subsequent times, and I'm hoping this will help me figure out the overall problem.
First Run:
"<Contact: 0x1fc7a000> (entity: Contact; id: 0x1fc79cb0 <x-coredata:///Contact/tC060241D-2C37-4F78-AA69-5FBE3CB9DDFB364> ; data: {\n email = nil;\n emails = (\n );\n name = \"AIB Dundrum\";\n nameInitial = A;\n parseID = nil;\n phoneNumber = 012983777;\n signedUp = 0;\n})"
Second Run:
"<Contact: 0x1e35f3f0> (entity: Contact; id: 0x1e2ab020 <x-coredata://FD1A50BA-9A08-452D-B4B4-2072FA1B190C/Contact/p337> ; data: <fault>)"
Can anybody explain to me the difference between these outputs, why the data is faulted like so the second time I run the app, and how I might make it do this the first time?
Thanks
回答1:
On your second run, you are seeing a fault, meaning that Core Data knows this object exists in the graph, but it doesn't know anything other than that. It needs to go back to the persistent store to get that other information, by using faulted objects Core Data can limit the size of the object graph in memory. One way to "fire a fault" is to access one of the object's properties. You can do this in the debugger by putting a breakpoint before you log the Contact NSManagedObject's description. Once the break point is hit, type the following into the debugger console.
po [myContact willAccessValueForKey:nil] this should fire the fault and then when you log the description you won't see data: <fault>, but rather all of the properties and their values, which is what you are seeing in "First Run".
One thing I am not sure of is why you see x-coredata:///Contact/tC060241D-2C37-4F78-AA69-5FBE3CB9DDFB364 in First Run and x-coredata://FD1A50BA-9A08-452D-B4B4-2072FA1B190C/Contact/p337 in Second Run. I feel pretty confident in saying that it seems that the Contact has not been saved yet in First Run, the p337 you see in Second Run actually represents the records ID in the backing persistent store. You should never rely on this ID but from my debugging and analysis experience that is what I have always seen to be the case. With that said, that is what leads me to believe that the Contact being logged in First Run has not yet been saved in the persisten store.
Hope that helps.
来源：https://stackoverflow.com/questions/14492052/what-is-causing-the-difference-in-this-core-data-output