Sorry if this is a bit late, I only saw this post today :)
For performance reasons, processPendingChanges: only gets called automatically after event processing in the runloop. It would be too expensive to call it after every single notification, timer invocation, etc. If you are changing your managed object context in response to anything but direct user input you must call processPendingChanges: manually for changes to take effect. Do not abuse this call, it can dramatically slow down your application if, for example, you call it after every single object creation, insertion, modification, or deletion... it is best to do all of your work in a batch before calling processPendingChanges:.
Some examples of when this is needed include a worker thread finishes loading some data and adds new data to the core data managed object context. (Of course, you did add that new data from the *main* runloop, correct?) , or a notification or timer gets triggered and you update some value.
The UI (and many internals of your app) will be out of sync with the expected state of the database....er... object-graph management and persistence thingamagigger (don't call it a database, the core data folks hate that :-D) until the user starts clicking around on the UI... at which point weird unexpected behavior might occur. My suggested approach would be to have the main thread load and process the data that was obtained in the [worker thread/posted notification userinfo / etc] and then have call [moc processPendingChanges:] before returning.
Hopefully this helps, it has saved my butt many times in the past and understanding why this is needed and how often to call it has helped keep my core data apps fast with a consistent 'database'.
by Mike Margolis — Oct 10
For performance reasons, processPendingChanges: only gets called automatically after event processing in the runloop. It would be too expensive to call it after every single notification, timer invocation, etc. If you are changing your managed object context in response to anything but direct user input you must call processPendingChanges: manually for changes to take effect. Do not abuse this call, it can dramatically slow down your application if, for example, you call it after every single object creation, insertion, modification, or deletion... it is best to do all of your work in a batch before calling processPendingChanges:.
Some examples of when this is needed include a worker thread finishes loading some data and adds new data to the core data managed object context. (Of course, you did add that new data from the *main* runloop, correct?) , or a notification or timer gets triggered and you update some value.
The UI (and many internals of your app) will be out of sync with the expected state of the database....er... object-graph management and persistence thingamagigger (don't call it a database, the core data folks hate that :-D) until the user starts clicking around on the UI... at which point weird unexpected behavior might occur. My suggested approach would be to have the main thread load and process the data that was obtained in the [worker thread/posted notification userinfo / etc] and then have call [moc processPendingChanges:] before returning.
Hopefully this helps, it has saved my butt many times in the past and understanding why this is needed and how often to call it has helped keep my core data apps fast with a consistent 'database'.