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 entities that I work with, an Outfit, and an Article. I can create them with no problem but when I delete them I get the follow error log:

For the Outfit:

2009-09-22 20:17:37.771 itryiton[29027:20b] Operation could not be completed. (Cocoa error 1600.)
2009-09-22 20:17:37.773 itryiton[29027:20b]   {
    NSLocalizedDescription = "Operation could not be completed. (Cocoa error 1600.)";
    NSValidationErrorKey = outfitArticleViewProperties;
    NSValidationErrorObject = <Article: 0x12aa3c0> (entity: Article; id: 0x12b49a0 <x-coredata://7046DA47-FCE1-4E21-8D7B-E532AAC0CC46/Article/p1> ; data: {
    articleID = 2009-09-22 19:05:19 -0400;
    articleImage = 0x12b4de0 <x-coredata://7046DA47-FCE1-4E21-8D7B-E532AAC0CC46/ArticleImage/p1>;
    articleType = nil;
    attributeTitles = "(...not nil..)";
    color = nil;
    comment = nil;
    dateCreated = 2009-09-22 19:05:19 -0400;
    designer = nil;
    imageView = "(...not nil..)";
    location = "(...not nil..)";
    outfitArticleViewProperties =     (
        0x12b50f0 <x-coredata://7046DA47-FCE1-4E21-8D7B-E532AAC0CC46/OutfitArticleViewProperties/p1>
    );
    ownesOrWants = 0;
    pattern = nil;
    price = nil;
    retailer = nil;
    thumbnail = "(...not nil..)";
    washRequirements = nil;
    wearableSeasons = nil;
});
    NSValidationErrorValue =     {(
        <OutfitArticleViewProperties: 0x1215340> (entity: OutfitArticleViewProperties; id: 0x12b50f0 <x-coredata://7046DA47-FCE1-4E21-8D7B-E532AAC0CC46/OutfitArticleViewProperties/p1> ; data: {
    article = 0x12b49a0 <x-coredata://7046DA47-FCE1-4E21-8D7B-E532AAC0CC46/Article/p1>;
    articleViewPropertiesID = nil;
    outfit = nil;
    touch = nil;
    view = "(...not nil..)";
})
    )};
}

And if I delete an Article I get:

2009-09-22 18:58:38.591 itryiton[28655:20b] Operation could not be completed. (Cocoa error 1560.)
2009-09-22 18:58:38.593 itryiton[28655:20b]   DetailedError: {
    NSLocalizedDescription = "Operation could not be completed. (Cocoa error 1600.)";
    NSValidationErrorKey = articleImage;
    NSValidationErrorObject = <Article: 0x12aa340> (entity: Article; id: 0x12b3f10 <x-coredata://05340FA6-B5DC-4646-A5B4-745C828C73C3/Article/p1> ; data: {
    articleID = 2009-09-22 18:58:26 -0400;
    articleImage = 0x12b4d00 <x-coredata://05340FA6-B5DC-4646-A5B4-745C828C73C3/ArticleImage/p1>;
    articleType = nil;
    attributeTitles = "(...not nil..)";
    color = nil;
    comment = nil;
    dateCreated = 2009-09-22 18:58:26 -0400;
    designer = nil;
    imageView = "(...not nil..)";
    location = "(...not nil..)";
    outfitArticleViewProperties =     (
        0x12b5010 <x-coredata://05340FA6-B5DC-4646-A5B4-745C828C73C3/OutfitArticleViewProperties/p1>
    );
    ownesOrWants = 0;
    pattern = nil;
    price = nil;
    retailer = nil;
    thumbnail = "(...not nil..)";
    washRequirements = nil;
    wearableSeasons = nil;
});
    NSValidationErrorValue = <ArticleImage: 0x12ad600> (entity: ArticleImage; id: 0x12b4d00 <x-coredata://05340FA6-B5DC-4646-A5B4-745C828C73C3/ArticleImage/p1> ; data: {
    article = 0x12b3f10 <x-coredata://05340FA6-B5DC-4646-A5B4-745C828C73C3/Article/p1>;
    image = "(...not nil..)";
});
}

A 1600 error is:

NSValidationRelationshipDeniedDeleteError
Error code to denote some relationship
with delete rule NSDeleteRuleDeny is
non-empty.

Available in Mac OS X v10.4 and later.

Declared in CoreDataErrors.h.

But I can't see for the life of me which relationship would be preventing the delete. If some Core Data wizard can see the error of my ways, I would be humbled.

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.

Answer 1

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.

Answer 2

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 3

Do you happen to implement some of the accessor to the relationship yourself? I once had a code like

-(NSSet*)articles
{
       re-calculates properties....
       return [self primitiveValueForKey:@"articles"];
}

in a subclass of NSManagedObject and had a save error. What happened was that, when this object is deleted from the ManagedObjectContext, the CoreData calls the accessor "articles" to deal with the delete propagation. This re-calculation of articles occurred during the delete propagation, which re-surrected the nullified "articles" in my case.

Answer 4

Check your xcdatamodel file for a Deny delete rule. Click on each relationship until you find it. You'll need to change this rule or adjust how you delete managed objects to anticipate the rule's application to the relationship.

Answer 5

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 6

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 7

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 8

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.