来自NSFetchedResultsController的节名称与托管对象值不匹配 [英] Section names from NSFetchedResultsController don't match the managed object values

问题描述

我使用NSFetchedResultsController来填充一个UITableView的结果从中等大小的Core数据存储〜1500实体。结果控制器是相当标准的 - 潜在错误的一些热点不是这个设置的真实。

• 创建的托管对象上下文


• 不使用缓存（因为排序变化频繁）


• sectionNameKeyPath用于拆分结果分成

然而，我的部分结果非常奇怪。例如，考虑这个方法用于设置节头部视图的标题：

   - （NSString *）titleForHeaderInSection：（NSInteger ）section {
 id< NSFetchedResultsSectionInfo> sectionInfo = [[self.resultsController sections] objectAtIndex：section]; 
 return [sectionInfo name]; // <-------在这里断点处停止
} 
  

I使用断点停止在指定的行，并使用GDB检查以下内容：

 （gdb）po [[self resultsController] sectionNameKeyPath] 
 reviewDateString 
（gdb）print section 
 $ 11 = 1 
（gdb）print（int）[sectionInfo numberOfObjects] 
 $ 12 = 4 $ b $ 2010年9月8日星期三
（gdb）po [[[SectionInfo objects] objectAtIndex：0] valueForKey：@reviewDateString] 
 2011年12月13日
（gdb）po [[[SectionInfo objects] objectAtIndex：1] valueForKey：@reviewDateString] 
 2011年2月13日星期日
 objectAtIndex：2] valueForKey：@reviewDateString] 
 2011年2月13日星期日
（gdb）po [[sectionInfo objects] objectAtIndex：3] valueForKey：@reviewDateString] 
星期日，2011年2月13日
  

问题应该很明显 - 为什么[sectionInfo name]的sectionNameKeyPath中的每个管理对象的部分？

如果你看到这个结果，结果更奇怪：

p>

 （gdb）po [[self resultsController] indexPathForObject：（id）[[sectionInfo objects] objectAtIndex：0]] 
 < NSIndexPath 0x6615660> 2 index [459，4294966310] 
  

现在显然，从上面的NSIndexPath返回应该是[1 ，0]，而不是这个伪造的值。

我完全被骗了。任何人都有什么想法？

$ b

我的NSFetchedResultsController设置的一个奇怪的事情是，我重新创建（释放和alloc / init一个新的）结果控制器响应UISegmentedControl的选择改变。这是为了更改fetch请求和sectionNameKeyPath的sortDescriptors，以便整个排序更改。

/ p>

resultsController方法只是我使用的NSFetchedResultsController的属性访问器，由@synthesize生成。

段名称的期望值已经给出 - 段名称应该等于我在po [sectionInfo name]下面显示的@reviewDateString键（这是sectionNameKeyPath）的值，

解决方案

您可能需要在抓取时修复sectionNameKey。

如果此键路径与fetchRequest中第一个排序描述符指定的键路径不同，则它们必须生成相同的相对顺序。例如，fetchRequest中的第一个排序描述符可能指定持久性属性的键; sectionNameKeyPath可以为从持久性属性派生的瞬态属性指定键。

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".

解决方案

You likely need to fix your sectionNameKey on the fetch.

If this key path is not the same as that specified by the first sort descriptor in fetchRequest, they must generate the same relative orderings. For example, the first sort descriptor in fetchRequest might specify the key for a persistent property; sectionNameKeyPath might specify a key for a transient property derived from the persistent property.

这篇关于来自NSFetchedResultsController的节名称与托管对象值不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！