Intercepting deletion of NSManagedObjects or how to handle deletion in non-explicit relationships?
Intercepting deletion of NSManagedObjects or how to handle deletion in non-explicit relationships?
- Subject: Intercepting deletion of NSManagedObjects or how to handle deletion in non-explicit relationships?
- From: Martin Stanley <email@hidden>
- Date: Wed, 28 Jul 2010 22:28:58 -0400
I have what I hope is an interesting modelling/technical problem.
I have a NSPersistentDocument application that implements the concept of smart groups. The user can create arbitrarily complex predicates to specify the conditions for group membership.
I have modelled this with a SmartGroup entity which has a name and predicate attributes. The predicate is evaluated at appropriate times to determine the smart group members. To construct and edit these smart group predicates, I use a subclass of NSPredicateEditor and its friends.
I also have other entities in my model; for example: Project or Area. The name attribute (NSString) of these entities are used as the right expression in the SmartGroup predicate. For example, the predicate might be:
project.name == "Project1"
where "project" is the relationship that points to the Project entity and "name" is the key field, at least for query purposes.
I am wondering how to handle the situation when, for example, the Project named "Project1" is deleted. The Project entity participates in bi-directional relationships with other (non-SmartGroup) entities in my model. When an entity is deleted Core Data takes care of cleaning up the references since the relationship is set to Nullify on deletion. This all works fine; the destination entity has this relationship set to null and it appears to the user that that this field is not set. This is acceptable behaviour for my app. If the name of the entity is changed things are also handled correctly because the Core Data relationship is between objects and does not depend on an individual field. The name change appears in all participating objects; the user interface is automatically updated.
With SmartGroups the situation is different. The relationship is not explicit; it is due to the fact that the entity's name is used in the predicate. If the user deletes the referenced entity the predicate will no longer be valid. This is possibly okay in that the predicate will return no group members. But if the entity is has its key field (name in this case) changed then the predicate will be incorrect; this is clearly not what the user expects to happen. Furthermore, the most serious problem is that it breaks NSPredicateEditor since there is no longer a popup menu item matching the deleted project. NSPredicateEditor cannot display this predicate so that the user can edit it to fix the problem.
I think it would be reasonable to let the user know that the proposed deletion will invalidate one or more existing SmartGroups and give him/her the option on how to deal with the situation. For a name change I could just silently update the predicate as long as I can arrange for a timely notification.
One possible solution is parse the SmartGroups's predicate each time it is set and then create an explicit bi-directional relationship between the SmartGroup object and the referenced entity. Then using KVO, I could determine all the SmartGroups that are referencing the to-be deleted entity. But I would need to do this before the entity is deleted, not wait until the save is attempted by Core Data.
So, before implementing the above solution, I thought I would post to the list to see if anyone has any suggestions for me. Am I modelling the situation correctly? Is it possible to accomplish what I want (essentially intercept entity deletion) in a reasonably elegant manner?
All comments are much appreciated.
Martin
PS - Sorry for the length of this post: I thought it would be useful to explain the situation in detail at the outset.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden