[[[NSFetchedResultsController sections] objectAtIndex:0] numberOfObjects] > fetchLimit

Question

I am currently having an issue where my UITableViewController/UITableView which uses an NSFetchedResultsController displays about 86 items when the fetchLimit on the fetchRequest for the FRC is 4. I know that 86 items satisfy the fetch itself, and I know that the reason that they appear is because the didChangeObject: atIndexPath... gets called for each of the 86, and I insert as is kind of the default implementation.

My question is why doesn't the fetchLimit limit the number of objects that the NSFetchedResultsController tries to "change" (insert in this case)?

My application use case is that the first tab displays typical feed items which I get (on a side thread) at app launch. I save them to CoreData on a separate context, which eventually merges to the main thread's context and initiates the FRC callbacks for what changed. My question pertains specifically to the initial case where no items exist.

---

Here is my fetchRequest:

    NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init] autorelease];
fetchRequest.entity = [NSEntityDescription entityForName:ENTITY_CONTENT_ITEM inManagedObjectContext:managedObjectContext];

// Set a limit on the number of items returned
[fetchRequest setFetchLimit:4];

// Set a Predicate to limit the fetch to featured items only
[fetchRequest setPredicate:[NSPredicate predicateWithFormat:@"featured == YES AND contentType == %d", contentType]];

// Set the sort descriptors
NSSortDescriptor *sortDateDescriptor = [[[NSSortDescriptor alloc] initWithKey:@"sortDate" ascending:NO] autorelease];
[fetchRequest setSortDescriptors:[NSArray arrayWithObject:sortDateDescriptor]];

The contentType above is simply a way to break out what is supposed to display in this tab versus other tabs. Featured is a boolean property on the item, which is more like an on off switch for display purposes.

Here is my didChangeObject:

- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath { 
  switch(type) {
    case NSFetchedResultsChangeInsert:
      [tableView insertRowsAtIndexPaths:[NSArray arrayWithObject:newIndexPath] withRowAnimation:UITableViewRowAnimationFade];
      break;
    case NSFetchedResultsChangeDelete:
      [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
      break;
    case NSFetchedResultsChangeUpdate:
      [tableView cellForRowAtIndexPath:indexPath];
      break;
    case NSFetchedResultsChangeMove:
      [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
       // Reloading the section inserts a new row and ensures that titles are updated appropriately.
       [tableView reloadSections:[NSIndexSet indexSetWithIndex:newIndexPath.section] withRowAnimation:UITableViewRowAnimationFade];
       break;
  }
}

I know it's going to be hard to answer this question, but even an explanation of how the FRC decides how many times to call didChangeObject would be really helpful.

Answer 1

https://devforums.apple.com/thread/60319?tstart=0

For those who can access this, check it out. The apple developer gives a good, quick summary of the changes to the CoreData/NSFetchedResultsController/UITableViewController stack in iOS4.0.

There were changes made in 3.2 and 4.0 to improve the caching and performance as well as fix known issues. The persistent caching is much more aggressive, and so people misusing the cacheName have run into trouble. Setting the cacheName to nil instead, or cleaning up usage and calling +deleteCacheWithName when appropriate are solutions to that. The section recalculation was improved to perform more computation via the database instead of in-memory whenever possible. Sectioning triggers whenever the cache is rebuilt (or if not using a cache, when performFetch is called). The .description workaround makes the keypath refer to an unmodeled property (the -description method) which cause the section calculation to work in memory instead since the db doesn't know anything about -description.

In 4.0, there were also changes to UITableView to fix a number of issues involving the UITableViewController delegate callbacks. People who needed to use -reloadData on earlier iOS releases to work around trouble should be able to use the finer grained callbacks on iOS4.

-BenT (Apple)

Given that, I added .description to my sectionNameKeyPath in my fetchedResultsController initWithFetchRequest call. This apparently makes the section calculation happen in memory instead of on disk, which fixed an issue with my sections thinking they had more items than they did.

That works for 4.0, and in 3.0 I just call reloadData in from the controllerDidChangeContent callback. Feel free to shoot me a message if you have similar problems.