views:

19

answers:

1

I'm a pretty comfortable CoreData user. I had a problem that was absolutely killing me, figured out what was going wrong and have NO CLUE why it was causing the problems I was seeing. Can anyone explain this?

Okay, we have a main MOC that does most the 'read-only' data work and handles simple write operations. When we're about to do a big write/import/etc, we allocate a background MOC on a new thread, do all the heavy work, then save it. Saving causes our NSManagedObjectContextWillSaveNotification to fire and then we mergeChangesFromContextDidSaveNotification: and everything on the main MOC reflects the changes. Pretty standard.

So a few days ago a change was made in one of the NSManagedObject subclasses. The change was a call in setValue:forKey:. When no special handling was done in that method, we were originally calling [super setValue: forKey:]. It was changed to [self setPrimitateValue: forKey:] and...

After a save the mergeChangesFromContextDidSaveNotification: would get called, but the main MOC wouldn't reflect the changes. So that's a bit weird. But close the application and then opening it again, the changes would magically BE THERE. What!?!

I know it's some problem with the persistant store saving the changes but not the other MOC. Then when the new MOC gets created new launch, everything is in sink again. Why?

Any light on this topic would help a bunch.

+1  A: 

setPrimitiveValue:forKey: doesn't cause all the kvo notifications to fire. I think this is the cause of your problem. You probably need to wrap it around willChangeValueForKey: and didChangeValueForKey: calls.

Elfred
But why would the KVO notifications matter? I'm not observing anything in particular and the NSManagedObjectContextWillSaveNotification was firing regardless.
beinstein