Question

I have three Entity Objects. The relationship between these entities is kinda love triangle!

Company <<----->> Department (many to many) (eg. HR Department is common to all companies)

Department <---->> Employee

Company <----->> Employee

to set an example,

John (employee1) belongs to BSKYU Company and works in Marketing)
Jason (employee2) belongs to IBC Compnay and works in in Finance)
**Note: Marketing is common to both John and Jason.

I wanted to develop a deletion routine, such that,

deleting Company would delete All its Employees
I also want to get rid of the department that is not part of any `Other Comapny’.
Hence if i delete IBC company, it should delete Jason (via cascade i guess), and also get rid of Finance department ONLY IF IBC is the ONLY COMPANY that had Finance department.
I somehow need to check if Finance.company == [zero result] if so , delete it.

DELETINGDEPARTMENT would delete all its Employees that belong to A Company that was selected before!
Assuming a company was aready selected, I’d and If I delete a deparment , say HR, i’d also want to delete all Employees within that Department THAT BELONGED TO THE SELECTED COMPANY

My question is, “WHERE” should i be handling such deletion rules, this comes across, but im not sure how to handle it:

- (BOOL)validateForDelete:(NSError **)error

What would be the most efficient way to handle the deletion, checking whether everything that needs to be deleted based on the above rules, should be.

any help is appreciated. thanks

Answer 1

You have to do it yourself with the proper predicate, you can use sample code below as a starting point but you’ll have to provide context, predicate, etc.

The delete rules are nice to ensure data integrity but if you have your special cases you have to Fetch the objects and delete them manually.

`// Create fetch request

NSFetchRequest *request = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:entityName inManagedObjectContext:managedObjectContext];
[request setEntity:entity]; 

// Ignore property values for maximum performance
[request setIncludesPropertyValues:NO];

// If a predicate was specified then use it in the request
if (predicate != nil)
    [request setPredicate:predicate];

// Execute the count request
NSError *error = nil;
NSArray *fetchResults = [managedObjectContext executeFetchRequest:request error:&error];

// Delete the objects returned if the results weren't nil
if (fetchResults != nil) {
    for (NSManagedObject *manObj in fetchResults) {
        [managedObjectContext deleteObject:manObj];
    }

`

Aside of this, in the datamodel inspector of the relationships you can specify delete rules :

But if you begin to say, i want it to be deleted only if “the employee is one legged, at work, but in the coffee room, except if the big boss is on holidays, then you have to code it.

From the Core Data Programming guide :

Relationship Delete Rules

A relationship’s delete rule specifies what should happen if an attempt is made to delete the source object. Note the phrasing in the previous sentence—”if an attempt is made…”. If a relationship’s delete rule is set to Deny, it is possible that the source object will not be deleted. Consider again a department’s employees relationship, and the effect that the different delete rules have.

Deny

If there is at least one object at the relationship destination, then the source object cannot be deleted.
For example, if you want to remove a department, you must ensure that all the employees in that department are first transferred elsewhere (or fired!) otherwise the department cannot be deleted.

Nullify

Set the inverse relationship for objects at the destination to null.
For example, if you delete a department, set the department for all the current members to null. This only makes sense if the department relationship for an employee is optional, or if you ensure that you set a new department for each of the employees before the next save operation.

Cascade

Delete the objects at the destination of the relationship.
For example, if you delete a department, fire all the employees in that department at the same time.

No Action

Do nothing to the object at the destination of the relationship.
For example, if you delete a department, leave all the employees as they are, even if they still believe they belong to that department.

It should be clear that the first three of these rules are useful in different circumstances. For any given relationship it is up to you to choose which is most appropriate, depending on the business logic. It is less obvious why the No Action rule might be of use, since if you use it you have the possibility of leaving the object graph in an inconsistent state (employees having a relationship to a deleted department).

If you use the No Action rule, it is up to you to ensure that the consistency of the object graph is maintained. You are responsible for setting any inverse relationship to a meaningful value. This may be of benefit in a situation where you have a to-many relationship and there may be a large number of objects at the destination.`

source : Core Data Programming Guide