NSFetchedResultsController - when are delegate methods fired?

I have a model with a many-to-many relationship between the following entities:

Meeting >---< Person

I'm using an NSFetchedResultsController to return all the people for a meeting (these are displayed in a custom view). The NSFetchRequest is created so:

NSSortDescriptor * lastNameSort = [NSSortDescriptor sortDescriptorWithKey: @"lastName" ascending: YES];
NSSortDescriptor * firstNameSort = [NSSortDescriptor sortDescriptorWithKey: @"firstName" ascending: YES];

request.entity = [NSEntityDescription entityForName: @"Person" inManagedObjectContext: context];
request.predicate = [NSPredicate predicateWithFormat: @"(ANY %K == %@)", @"meetings", self];
request.sortDescriptors = [NSArray arrayWithObjects: lastNameSort, firstNameSort, nil];

Calling -[Meeting addPeopleObject:] for a single person works fine - the delegate methods for the NSFetchedResultsController are fired correctly, and I can update the custom view.

I have a problem adding multiple people to a meeting. A method loops through an array of people, calling -[Meeting addPeopleObject:] for each person. The first time I do this, NSFetchedResultsControllerDelegate methods are 开发者_如何学Cfired after adding each person. So if I add 5 people, controllerWillChangeContent: then controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: then controllerDidChangeContent: are fired 5 times.

If I create a second Meeting object, and then add the same 5 people to this meeting, the willChange and didChange delegate methods are only fired twice, once after the first person, and once after the final person. The controller:didChangeObject:... method is called 5 times as expected, but not in the order the people were inserted.

Is this expected behaviour for an NSFetchedResultsController? Is there some cacheing causing this to happen (the NSFetchedResultsController was created with nil cache). Is there a way to force the `NSFetchedResultsControllerDelegate' methods to fire after each update?

---

Notifications are not guaranteed to show up in any kind of order so that is not an issue.

As long and the call order goes willChange-->controller:didChangeObject:--> didChange there is not a problem as long as all the changes occur between the willChange and the didChange.

Most likely, what you are seeing is the different notifications sent between first use and subsequent use. In the first use, the managed objects are most likely faults and reading them in fully (faulting or firing the fault) triggers a notification for each object. However, once they are fully active adding them all at once again just triggers a single notification.

This is probably one of Core Data's behind the scenes optimizations. As long as the table updates properly, I would worry about it.