NSFetchedResultsController 中的部分名称与托管对象值不匹配
我正在使用 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],而不是这个伪造的值。
我完全被难住了。有人有什么想法吗?如果您需要更多信息,我会关注这个问题。
[编辑 1]
关于我的 NSFetchedResultsController 设置的一件奇怪的事情是,我重新创建(释放并分配/初始化一个新的)结果控制器以响应 UISegmentedControl 的选择更改。这样做是为了更改获取请求的 sortDescriptors 和sectionNameKeyPath,从而使整体排序发生变化。
[编辑 2]
resultsController 方法只是我正在使用的 NSFetchedResultsController 的属性访问器,由 @synthesize 生成。
部分名称的预期值已给出 - 部分名称应等于我在“po [sectionInfo name]”下方显示的 @"reviewDateString" 键(即sectionNameKeyPath)的值,因此对于本例它们应该是“2011 年 2 月 13 日星期日”。
I'm using an NSFetchedResultsController to populate a UITableView with results from a moderately sized Core Data store of ~1500 entities. The results controller is fairly standard - some "hot spots" for potential bugs aren't true of this setup.
- Managed object context created on the same (main) thread as its used on
- No cache is used (because the sort changes frequently)
- A sectionNameKeyPath is used to split the results into sections
My section results, however, are very odd. For example, consider this method used to set the titles for the section header views:
- (NSString *)titleForHeaderInSection:(NSInteger)section {
id <NSFetchedResultsSectionInfo> sectionInfo = [[self.resultsController sections] objectAtIndex:section];
return [sectionInfo name]; // <------- Stopped at breakpoint here
}
I've stopped at the indicated line using a breakpoint and, using GDB, examined the following:
(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
The issue should be evident - why doesn't [sectionInfo name] match the values of the sectionNameKeyPath for each managed object in the section? The objects in the section appear to be properly grouped, the section name just isn't correctly set.
The results are even more odd if you look at this:
(gdb) po [[self resultsController] indexPathForObject:(id)[[sectionInfo objects] objectAtIndex:0]]
<NSIndexPath 0x6615660> 2 indexes [459, 4294966310]
Now obviously, from the above, the NSIndexPath returned should be [1,0], not this bogus value.
I'm completely stumped. Anyone have any ideas? I'll be watching this question in case you need more information.
[Edit 1]
The one odd thing about my NSFetchedResultsController setup is that I recreate (release and alloc/init a new one) the results controller in response to a UISegmentedControl's selection changing. This is done in order to change the sortDescriptors of the fetch request and sectionNameKeyPath, so that the overall sort changes.
[Edit 2]
The resultsController method is just the property accessor for the NSFetchedResultsController that I'm using, generated by @synthesize.
The expected values for the section names are given already - the section names should be equal to the values for the @"reviewDateString" key (which is the sectionNameKeyPath) that I showed just below "po [sectionInfo name]", so for this case they should be "Sunday, February 13th 2011".
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可能需要在获取时修复您的sectionNameKey。
You likely need to fix your sectionNameKey on the fetch.