Question

I have entities that are managed by Core Data and have several cases where, within a single method, I set some attribute values that will result graph changes that Core Data will enforce and perform additional actions that (logically) depend on uptodate state for the graph.

Is there any reason not to call processPendingChanges after each time a relationship is set, to ensure that the graph is always fully uptodate? Everything works as it should when I do this, but, clearly, it’s a bit “noisy”, and breaks up some processing that would otherwise be notifications (e.g, fetched results controllers that end up sending lots of controllerWillChangeContent/controllerDidChangeContent to their deligates when one would otherwise have happened).

ADDITION:

Will the graph always be up-to-date after a return from any method that makes changes to an entity?

Answer 1

processPendingChanges is most often used on iOS with multiple context operating on seperate threads. It plays a bigger and more common role under MacOS.

You usually don’t have to call it under iOS in most circumstances. Doing so doesn’t really give you much of an advantage and it can cause lags in the UI when executed on the main thread if you have a complex graph.

I wouldn’t bother with it unless testing reveals you are loosing graph integrity for some reason.