我正在使用 NSFetchedResultsController 用大约 1500 个实体的中等大小的核心数据存储的结果填充 UITableView。结果控制器相当标准 - 一些潜在错误的“热点”并不适合此设置。
- 在与其使用的同一（主）线程上创建的托管对象上下文
- 不使用缓存（因为排序经常改变）
- sectionNameKeyPath 用于将结果拆分为多个部分
然而，我的部分结果非常奇怪。例如，考虑此方法用于设置节标题视图的标题：
- (NSString *)titleForHeaderInSection:(NSInteger)section {
id <NSFetchedResultsSectionInfo> sectionInfo = [[self.resultsController sections] objectAtIndex:section];
return [sectionInfo name]; // <------- Stopped at breakpoint here
}
我已使用断点停在指定的行，并使用 GDB 检查了以下内容：
(gdb) po [[self resultsController] sectionNameKeyPath]
reviewDateString
(gdb) print section
$11 = 1
(gdb) print (int) [sectionInfo numberOfObjects]
$12 = 4
(gdb) po [sectionInfo name]
Wednesday, September 8th 2010
(gdb) po [[[sectionInfo objects] objectAtIndex:0] valueForKey:@"reviewDateString"]
Sunday, February 13th 2011
(gdb) po [[[sectionInfo objects] objectAtIndex:1] valueForKey:@"reviewDateString"]
Sunday, February 13th 2011
(gdb) po [[[sectionInfo objects] objectAtIndex:2] valueForKey:@"reviewDateString"]
Sunday, February 13th 2011
(gdb) po [[[sectionInfo objects] objectAtIndex:3] valueForKey:@"reviewDateString"]
Sunday, February 13th 2011
问题应该很明显 - 为什么 [sectionInfo name] 与该部分中每个托管对象的sectionNameKeyPath 的值不匹配？该部分中的对象似乎已正确分组，只是部分名称设置不正确。
如果你看看这个，结果会更奇怪：
(gdb) po [[self resultsController] indexPathForObject:(id)[[sectionInfo objects] objectAtIndex:0]]
<NSIndexPath 0x6615660> 2 indexes [459, 4294966310]
现在显然，从上面来看，返回的 NSIndexPath 应该是 [1,0]，而不是这个伪造的值。
我完全被难住了。有人有主意吗？如果您需要更多信息，我会关注这个问题。
[Edit 1]
我的 NSFetchedResultsController 设置的一件奇怪的事情是，我重新创建（释放并分配/初始化一个新的）结果控制器以响应 UISegmentedControl 的选择更改。这样做是为了更改获取请求的 sortDescriptors 和sectionNameKeyPath，从而使整体排序发生变化。
[Edit 2]
resultsController 方法只是我正在使用的 NSFetchedResultsController 的属性访问器，由 @synthesize 生成。
部分名称的预期值已给出 - 部分名称应等于我在“po [sectionInfo name]”下方显示的 @"reviewDateString" 键（即sectionNameKeyPath）的值，因此对于本例它们应该是“2011 年 2 月 13 日星期日”。
