Restkit + Coredata - NSFetchedResultsControllerDelegate callbacks not triggered for UPDATE operations alone

Question

I have a strange problem here. I am not getting the callbacks for "Update" operations on my NSManagedObject, but where as any objects inserted into or removed from the collection of that entity type would trigger the delegate callbacks.

Before I proceed with the question further, I would like to inform about my setup:

• NSFetchedResultsController is properly configured. Made sure that the property which is being modified externally is not any of the sort keys for the fetchedResultsController as required by this Apple documentation:

  An update is reported when an object’s state changes, but the changed attributes aren’t part of the sort keys.

• There is only single managed object context in which these modifications are happening.

• Since insert and delete operations are being reported to the delegate, I presume there is something fishy about the Update operations

I was drilling down the Restkit code with help of RKLogs to see where exactly the mapping happens and where the coredata object is being updated to find out the reason why am not getting the update delegate callbacks.

In the class RKManagedObjectMappingOperation -performMapping method, Mr. Blake Watters has documented the reason why MOC callbacks are not triggered upon updates:

- (BOOL)performMapping:(NSError **)error
{
    BOOL success = [super performMapping:error];
    if ([self.objectMapping isKindOfClass:[RKManagedObjectMapping class]]) {
        /**
         NOTE: Processing the pending changes here ensures that the managed object context generates observable
         callbacks that are important for maintaining any sort of cache that is consistent within a single
         object mapping operation. As the MOC is only saved when the aggregate operation is processed, we must
         manually invoke processPendingChanges to prevent recreating objects with the same primary key.
         See https://github.com/RestKit/RestKit/issues/661
         */
        [self connectRelationships];
    }
    return success;
}

But I cannot for the life of myself figure out how to fix this? Coz it was done purposefully?

Has anyone faced same problem? How do I fix it?

Thanks, Raj Pawan

Answer 1

There was 1 mistake from my part and 1 other thing (Ignorance) which I was not aware of and due to which I faced this problem:

Mistake:
Despite many discussion all over the forums, I was wrong to state my second listed item:

• There is only single managed object context in which these
  modifications are happening.

I had wrongly logged and found out that I was in the same context! So dumb of me!

Ignorance:
I did some digging through the RK code thinking something fishy is going on there, checked Blake Watters' comments and his commit 4b394f8c1e1f to see if the earlier code there (call to -processPendingChanges) which is now removed was causing any issue and not letting the delegate to be informed about updates.

Found out that this was indeed on a separate thread and yes it had its own MOC which I had missed out. Next thing to do was simple, I implemented the mechanism to merge changes of a MOC from different thread into main MOC. But this did not work either!

The reason turns out that I am in a very initial stages of the development of application. I am just mapping the json response with coredata objects using RestKit and I am nowhere utilising it! I was just logging the coredata objects in GDB and they remained in their fault state always! I was relying upon the -objectLoader callbacks and the NSNotification object to see that there was indeed an Update available. At some point while testing I happened to log a property of the managed object which is changed in the Notification callback before it was merged back to the main MOC. This faulted the managed object and loaded all properties of the managed object. Now when the secondary thread MOC changes were merged with the main thread MOC, my NSFetchedResultsControllerDelegate callbacks started triggering.