CoreData not documented UserInfo Notification

Question

Created 2w

Replies 3

Boosts 0

Participants 2

Hello,

the last days I was trying to solve a bug in my Unit Tests related to the CoreData "NSManagedObjectContextObjectsDidChange" Notification.

Im using some kind of Notification handler to save and abstract that for the UI and while the tests are running this notification was triggered with objects that doesn't exists anymore, which has resulted in a crash.

After some debugging I have detected, that the objects in here are really old. The objects here was from few tests ago, where a Merge Conflict happened. In the meantime there was a plenty of resets and deletes of the whole db. I have also seen that the bad notification is the first in the stack trace of the main thread, which is in my opinion also not usual.

So the real question is: The only difference what I have found for the bad notification to the real notification, was the existence of the key "NSObjectsChangedByMergeChangesKey" in the UserInfo dictionary of the ObjectsDidChange Notification. But this key is nowhere found in the documentation of Apple. Also the search engines does not produce any result. So what is this key and when is this key contained in this notification and when not?

Maybe if I understand this, it helps me to understand the overall issue ...

Boost

Answer 1

DTS Engineer OP

Apple

1w

As far as I can tell, the value of NSObjectsChangedByMergeChangesKey, if not nil, indicates that some changes being merged to the managed object context were actually made at earlier time (but the merge was deferred for some reason). I'm unclear what can trigger the deferring, however. If you have a reproducible case, I'll be interested in taking a closer look.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0

Answer 2

wastene OP

1w

Hello @DTS Engineer,

with following you can reproduce that, but I think I have found the issue in the meantime (see at the bottom):

Setting up CoreData with 2 different Contexts. Setting viewContext property viewContext.automaticallyMergesChangesFromParent = true. Setting some Merge Policy for both contexts (as long as error is not used). Setting up some Singleton or something else which registers to the ObjectsDidChange Notification of CoreData. Using there some property of the Managed Objects. Date Property seems to results in Crashes, primitive properties not.

Creating Unit Tests which provacate a Merge Conflict. Merge Conflict should be created on the second context. So changing something on viewContext, then on the second context fetching the same object and doing some changes. Save viewContext and then save the second context.

For the tearDown I have cleared up the contexts (context.reset(), context.refreshAllObjects()).

Then doing some other Unit Tests which rans after and then the Notification appeared (or in my case it crashed) with the given key from above.

My assumption

My first assumption was, that the Merge Conflict is the problem. But I think the real issue has arised because I use a second context in the Unit Tests (only for the Merge Conflict testing). With the combination of viewContext.automaticallyMergesChangesFromParent = true it seems to result into that behavior.

Because if I set viewContext.automaticallyMergesChangesFromParent = false this notification is not triggered anymore.

Summary

It would be really helpful to document in the future such keys, to understand such notifications. In the meantime this post can be used for future reference.

0

Answer 3

DTS Engineer OP

Apple

1w

Thanks for sharing the scenario that can lead to invalid objects in the userInfo of the NSManagedObjectContextObjectsDidChange notification, which indeed is something need to be cautious when using the notification to detect changes.

Do you have a feedback report against the lack of documentation yet? If not, would you mind to file one and share your report ID here? I can file a report as well, but you represent the developer community and have a concrete use case. Thanks.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0