Question

我在使用NSFetchedResultsController时遇到困难，我在第一次运行应用程序时会返回0个部分，但是当我关闭并随后重新加载应用程序时会返回正确数量的部分。

我注意到如果我NSLog数组[[self.fetchedResultsController fetchedObjects] description]，我在第一次和随后的时间之间得到的结果略有不同，我希望这能帮助我弄清楚整体问题。

首次运行：

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

第二次运行：

"<Contact: 0x1e35f3f0> (entity: Contact; id: 0x1e2ab020 <x-coredata://FD1A50BA-9A08-452D-B4B4-2072FA1B190C/Contact/p337> ; data: <fault>)"

任何人都可以向我解释这些输出之间的区别，为什么第二次运行应用程序时数据出现故障，以及我第一次如何做到这一点？

由于

Answer 1

在第二次运行时，您看到fault，这意味着Core Data知道图中存在此对象，但除此之外不知道任何其他内容。它需要回到持久性存储来获取其他信息，通过使用故障对象Core Data可以限制内存中对象图的大小。 “触发故障”的一种方法是访问对象的一个属性。您可以在调试器中通过在记录Contact NSManagedObject的描述之前放置断点来执行此操作。一旦达到断点，在调试器控制台中键入以下内容。

po [myContact willAccessValueForKey:nil]这应该会触发错误，然后当您记录描述时，您将看不到data: <fault>，而是所有属性及其值，这就是您在“First”中看到的内容运行”。

我不确定的一件事是您在首次运行中看到x-coredata:///Contact/tC060241D-2C37-4F78-AA69-5FBE3CB9DDFB364而在第二次运行中看到x-coredata://FD1A50BA-9A08-452D-B4B4-2072FA1B190C/Contact/p337。我非常有信心说在第一次运行中似乎尚未保存联系人，您在第二次运行中看到的p337实际上代表了支持持久性存储中的记录ID。你不应该依赖这个ID，而应该依赖我的调试和分析经验，这是我一直以来的看法。话虽如此，这就是让我相信首次运行中登录的联系人尚未保存在持久存储中的原因。

希望有所帮助。

造成此核心数据输出差异的原因是什么？

1 个答案: