Core Data Relationships cause save error after delete

Question

This question is probably a long shot. I can\'t figure out the errors I\'m getting on my core data project when I save after I delete an entity.

I have two main enti

Answer 1

I just had the problem of delete fail, and landed on this question. And I've figured out my problem and thought that I'd share that too and maybe someone will have the same problem as well.

The mistake I made is that the object (A) I am trying to delete have a relationship to another object (B) with NULL as delete rule. However, object B also have a relationship to A and it's non-optional. Therefore, when I delete A, B's relationship of A becomes null which is not allowed. When I change the delete rule to cascade and it worked.

Answer 2

I had a similar problem where it turned out the problem was in the .xib file. When I switched on the check box for "Deletes Objects on Remove" (under Bindings->Content Set) of the relevant Array Controller, the problem went away.

Don't know if this will help in your case, but I've had a lot of hairs go gray over problems that turned out be hidden away somewhere inside Interface Builder.

Answer 3

I recently encountered this error because I had code in the - (void)willSave method which updated some of the properties of the delete managed object after - (BOOL)isDeleted already returned true.

I fixed it by:

- (void)willSave {
    if (![self isDeleted]) {
    //Do stuff...
    }
}

Answer 4

In my case I have innocently created custom method in my subclass of NSManagedObject: isDeleted. I was encountering strange save exceptions until I removed / renamed it. After losing my sanity, I read documentation again more through-fully this time. It turned out I overridden one of the NSManagedObject methods one MUST NOT OVERRIDE.

Check if this excerpt from docs helps you:

Methods you Must Not Override

NSManagedObject itself customizes many features of NSObject so that managed objects can be properly integrated into the Core Data infrastructure. Core Data relies on NSManagedObject’s implementation of the following methods, which you therefore absolutely must not override: primitiveValueForKey:, setPrimitiveValue:forKey:, isEqual:, hash, superclass, class, self, isProxy, isKindOfClass:, isMemberOfClass:, conformsToProtocol:, respondsToSelector:, managedObjectContext, entity, objectID, isInserted, isUpdated, isDeleted, and isFault, alloc, allocWithZone:, new, instancesRespondToSelector:, instanceMethodForSelector:, methodForSelector:, methodSignatureForSelector:, instanceMethodSignatureForSelector:, or isSubclassOfClass:.

Besides - there are other methods you can override but you MUST CALL super implementation like or call: willAccessPrimitiveForKey, didAccessPrimitiveForKey in accessors and willChangevalueForKey, didChangeValueForKey in setters....

Answer 5

I was encountering a very similar issue with cascading deletes, on non optional parent-child relationships. It was very confusing because I thought the parent relationship delete rule was set to cascade. It turns out that the data model editor in Xcode was not saving the delete rule. I would set it to Cascade, go to a different view and come back and it would be set to nullify again. I had to restart Xcode and set the delete rule to cascade. After I did this everything worked.

So if anyone else encounters this issue double check that Xcode is saving your delete rules before delving into more complicated solutions.

By the way I'm using core data on iOS with Xcode 5's data model editor.

Answer 6

I can't mark this solved, because I didn't really solve it, but I do have a working work-around. In the .m for each of my managedObjects I added a method that looks like:

-(void) deleteFromManangedObjectContext{ 
   self.outfit = nil; 
   self.article = nil; 
   [[self managedObjectContext] deleteObject:self]; 
} 

So you can see, first I manually nil out the relationships, and then I have the object delete itself. In other objects, instead of nil-ing, my delete method is called on some of the objects relationships, to get a cascade.

I'm still interested in the "right" answer. But this is the best solution I have, and it does allow for some fine-grained control over how my relationships are deleted.