4

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?

orome
  • 45,163
  • 57
  • 202
  • 418

2 Answers2

4

I found it the hard way that you should call processPendingChanges before inspecting deletedObjects of NSManagedObjectContext. At least if some relationships have deleteRule set to NSCascadeDeleteRule.

If you don't call processPendingChanges then deletedObjects may not contain objects that will be deleted by cascade at the end of current event.

pointum
  • 2,987
  • 24
  • 31
2

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.

TechZen
  • 64,370
  • 15
  • 118
  • 145
  • The issue is that I need to examine relationships in the graph before the model would otherwise be enforced. – orome Apr 18 '11 at 22:30
  • When you set a relationship, it becomes immediately available from both sides of the relationship owing to Key-Value-Observing. I've seen very few circumstances (on a single thread) in which you had to anything to update the object graph. Unless you know for certain you are having problems with graph integrity I would not bother. Always choose the simplest design and then add in complexity only when testing proves you need it. – TechZen Apr 19 '11 at 00:05
  • Premature optimization is the root of all programming evil. – TechZen Apr 19 '11 at 00:06
  • I'm asking because I do, in fact (not hypothetically), need to have a look at the graph before some just-made changes would otherwise be processed. So the question remains: is there a disadvantage to breaking up the processing of pending changes into multiple calls to processPendingChanges vs. just letting them be processed as a bunch, normally (which would require a redesign)? – orome Apr 19 '11 at 04:15
  • 2
    processPendingChanges can trigger a cascade of side effects so if your graph is complex and has a lot of side effects e.g. calculated attributes, then making the call every time risk stalling the app at random. Therefore, I wouldn't recommend doing it every time. – TechZen Apr 19 '11 at 08:29
  • You don't need to call processPendingChanges just because you "need to have a look at the graph." The graph will in a usable state automatically in the vast number of cases. Have you actually tested that you can't use the graph without calling processPendingChanges or do you just assume that you need to? – TechZen Apr 19 '11 at 08:31
  • Yes, I've looked. Basically, I have a graph with a pretty standard structure. It has Things, which can have one previousThing, and collections of children, ancestors, and descendants. previousThing and children are reciprocals in the data model. When previousThing, a custom setter adds the previous thing to a thing's ancestors, and to descendants of all ancestors. – orome Apr 19 '11 at 15:39
  • Maybe I should ask from another angle (added above): will the graph always be up-to-date after a return from any method that makes changes to an entity? – orome Apr 19 '11 at 16:45
  • I've fixed it now so that I don't need to "look at" the graph in cases where it will not have been updated by core data (the answer to the follow-on question appears to be 'yes'), which simplifies things considerably. Thanks! – orome Apr 19 '11 at 20:40