Question

I have an NSManagedObject entity which override validateForInsert and validateForUpdate.

This methods return NO correctly when something is wrong in object consistency, based on some logic I wrote.

The application is a classic uitableview backed by an NSFetchedResultsController, with a detail view controller.

When I add a new entity the detail view controller is instantiated with a nil objectID, and pushed into the navigation stack.
When I pop the detail controller the [context save:&error] is called, and by putting some breakpoint I discovered that the fetched delegate method are fired once when I add a new entity, even when the validateForInsert return NO, and includePendingChanges is set to NO too.

When I retry to pop again the detail controller, the save is of course invoked again, the validate method too, but this time the NSFetchedResultsControllerDelegate are not fired.

I would like to know if this is normal behavior, or if I am missing something in my model.

[UPDATE]

This the stack trace after a breakpoint in delegate methods:

#0  0x0003e5ba in -[MyTableViewController controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:] at ......
#1  0x011512f9 in -[NSFetchedResultsController(PrivateMethods) _managedObjectContextDidChange:] ()
#2  0x00b46a29 in __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 ()
#3  0x01759855 in ___CFXNotificationPost_block_invoke_0 ()
#4  0x01759778 in _CFXNotificationPost ()
#5  0x00a8b19a in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#6  0x0106a673 in -[NSManagedObjectContext(_NSInternalNotificationHandling) _postObjectsDidChangeNotificationWithUserInfo:] ()
#7  0x01101f5e in -[NSManagedObjectContext(_NSInternalChangeProcessing) _createAndPostChangeNotification:withDeletions:withUpdates:withRefreshes:] ()
#8  0x01065ad3 in -[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] ()
#9  0x0106916b in -[NSManagedObjectContext save:] ()
#10 0x00004490 in -[MyAppDelegate saveContext:]

It can be seen that the validate is not called, even though the save is invoked on context, and this therefore make the fetched controller delegate to be fired.

[UPDATE 2]

In particular, don’t know if it is related, this is causing an exception (not always) in controllerDidChangeObject:

CoreData: error: Serious application error. An exception was caught
from the delegate of NSFetchedResultsController during a call to
-controllerDidChangeContent:. Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section
after the update (4) must be equal to the number of rows contained in
that section before the update (3), plus or minus the number of rows
inserted or deleted from that section (0 inserted, 0 deleted) and plus
or minus the number of rows moved into or out of that section (0 moved
in, 0 moved out). with userInfo (null)

and infact in the origin table has three rows, just because the context bypass the validateFor methods when object is created in context seems that a row is inserted, there is inconsistency in rows number.

The controller delegate are quite simple and standard:

-(void)controllerWillChangeContent:(NSFetchedResultsController*)controller {
   [self.tableView beginUpdates];
}

- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath {
   // for testing purpose I am not doing any modification
   return;
}

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

Still I don’t know who is updating the table view

Answer 1

I think this is normal behaviour; the fetched results controller doesn’t require a save before it shows changes. If you don’t want the changes made in your detail view to appear in the master before they’re saved, you’ll have to make a separate NSManagedObject context for the detail view. That way, only objects that are saved to the persistent store will make it back to the fetched results controller.