Preface:
I have two entities defined as a one-to-many relationship: A <<-------> B. B's relationship to A is called myAs and is a to-many relationship with Nullify as the Delete Rule. The inverse relationship from A to B is a to-one relationship with Cascade as the Delete Rule.
I have implemented validateForDelete on the B class like so:
- (BOOL)validateForDelete:(NSError **)error {
[super validateForDelete:error];
BOOL validDelete = FALSE;
if ([self.myAs count] == 0) {
validDelete = TRUE;
}
return validDelete;
}
The purpose of this is to delete the object B only if there are no more A objects in a relationship with it (but always delete the B object if there are no longer any A objects in a relationship with it). This validateForDelete works as intended if I check for this validation manually before a save: on a B object deletion:
if ([b validateForDelete:NULL]) {
//delete b object...
[context save:&error];
...
}
The problem I am having is when a delete of a B object is being cascaded from an A object deletion. Users will not have access to B objects directly--they are created and deleted via A objects. Therefore, my rule that B objects are to be deleted when there are no more A object associated with it must be enforced from the A object--hence the cascade on delete.
The problem is that when I delete an A object, the validateForDelete is called on the B object because of the cascade. I am getting an resolved error: Unresolved error (null), (null) because I am not calling the validateForDelete manually.
Question(s):
How do I access the validateForDelete call from a cascading delete programmatically so that I can pass in an error variable and/or handle a validateForDelete result of FALSE?
If the above is not possible, how should I be handling this use case? Is there another more practical way of achieving this?
Thanks in advance.
First, your call to super is ignoring its response and it is not acting on the response from the super. That is generally a bad idea.
Second, when you say NO to the validateForDelete it will throw an exception because the delete rule cannot be completed; in this case the cascade delete. In short, the validate method is not the correct place to be trying to handle this situation.
To handle this situation you should be overriding the -prepareForDeletion
method in the A class and have it peek at any Bs that fit that situation and delete them as appropriate. You will also want to change the delete rule to nullify instead of cascade. I would implement it as follows:
- (void) prepareForDeletion
{
[super prepareForDeletion];
if (![self myB]) return; //I don't have a B
if ([[[self myB] myAs] count] > 1) return; //Has more relationships
[[self managedObjectContext] deleteObject:[self myB]];
}
This will check to see if you have a B and if you do if that B has more than one relationship and if it doesn't, add it to the queue for deletion. Otherwise it will allow Core Data to just nullify the relationship.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With