CODEWITHSUNDEEP
cocoa-touchcore-dataionsmanagedobject
Ben Packard
Ben Packard

Reputation: 26476

Understanding Core Data and Saving an NSManagedObjectContext after a deletion

I have a core data generated class, 'item'. It has a property of 'type', which is another class.

I have customized 'setType' so that some other processing takes place - for example I update the 'dateTypeLastSet'. This is working fine so far.

However, for some reason, this additional processing is happening also when I delete the item. Specifically, it doesn't happen until I call 'save' on the NSManagedObjectContext.

Is this because the deletion causes an automatic call to 'setType:nil'? Logging the parameters shows that NULL is the attempted assignment.

This is going to be problematic for me, since amongst my additional processing code I perform some calculations. Let's pretend I store some counter of 'number of times an item's type is set' in there. I don't want the deletion and setting to nil to be counted. But I also can't just check for nil, since this might be a legitimate update (nil as a type might be acceptable).

Any explanations or advice is appreciated.

UPDATE

It turns out that when type is deleted, it does indeed set that attribute to nil - I noticed that the data entity's delete rule is nullify by default. If change it to no action, I don't have this problem.

So the question now becomes - what are the other effects of changing the delete rule from nullify? Why is this seen as the sensible default?

Upvotes: 0

Views: 216

Answers (1)

Phillip Mills
Phillip Mills

Reputation: 31016

It seems that nullify is a sensible default because, once the 'type' no longer exists, having a stray pointer to it could be dangerous. If you look up the NSNoActionDeleteRule in the docs, it says:

"If you use this rule, you are responsible for maintaining the integrity of the object graph. This rule is strongly discouraged for all but advanced users."

Upvotes: 1

Related Questions