3

I have an NSFetchedResultsController that is fetching results from a managed object context of NSMainQueueConcurrencyType. I also have another managed object context that shares the same NSPersistentStoreCoordinator of NSPrivateQueueConcurrencyType.

All changes are happening on the background context and being propagated to the main context with NSManagedObjectContextDidSaveNotification.

I had some problems getting certain changes to trigger NSFetchedResultsControllerDelegate methods as described here, but even after fixing that problem, I find that fetchedObjects sometimes returns incorrect data with duplicate objects.

The only workaround I can find is to add a performFetch call to controllerDidChangeContent:

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {
    [self.tableView endUpdates];

    // fetchedObjects is incorrect unless I refetch here...
    [controller performFetch:nil];
}

But this seems like an inefficient hack to me. I'm running my entire query every time any data changes. I've also disabled all caching in my NSFetchedResultsController, for the record.

Community
  • 1
  • 1
ninjudd
  • 553
  • 4
  • 11
  • Just a general question. Any reason why you are not using child/parent context stack? I've seen these errors before. – Léo Natan Sep 12 '14 at 19:53
  • I considered it, but based on http://robots.thoughtbot.com/core-data, it seems that a main and private context is slightly simpler. – ninjudd Sep 12 '14 at 20:42
  • Child/parent stack is the new and preferred method of Core Data context management. Also, it is a lot simpler to maintain. – Léo Natan Sep 12 '14 at 20:53
  • Thanks Leo, do you have a link to the Apple docs or a WWDC session recommending it? – ninjudd Sep 13 '14 at 02:11
  • Not on top of my head. I can tell you from my experience. But they were introduced in 2011, so you can check the What's New in Core Data. Also, make sure to read the documentation. – Léo Natan Sep 13 '14 at 02:26
  • Hmm... This blog post seems to say that there are performance tradeoffs to using nested contexts. It certainly seems easier though, and if it fixes my problem, it may be worth it. http://floriankugler.com/blog/2013/5/11/backstage-with-nested-managed-object-contexts – ninjudd Sep 13 '14 at 04:26
  • It depends on what your usecase is. As you can see, [I've pondered on this issue myself](http://stackoverflow.com/questions/13204589/core-data-managed-object-context-design-recommendation), and finally came to the conclusion that this was the most stable and less buggy way to do stuff. – Léo Natan Sep 13 '14 at 11:01
  • I have a similar Core Data stack and am seeing this issue in a very specific case. `fetchedObjects` contains some objects that are the wrong type after changes from a background context are merged into the main context. I'm using filteredArrayWithPredicate: to filter fetchedObjects. This can crash if the objects are updated in the background after the FRC is initially created and fetched. Filtering based on fast-enumeration resolves it. Your solution also resolves it. Thanks! – Jesse Jan 22 '16 at 00:27
  • @ninjudd Did you ever come up with a permanent solution to this issue? I'm experiencing a very similar problem currently. – AnthonyMDev Aug 31 '16 at 00:49

0 Answers0