Re: Cocoa-dev Digest, Vol 7, Issue 777
Re: Cocoa-dev Digest, Vol 7, Issue 777
- Subject: Re: Cocoa-dev Digest, Vol 7, Issue 777
- From: Martin Stanley <email@hidden>
- Date: Thu, 29 Jul 2010 19:59:23 -0400
Thanks for the response,
>> 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?
>
> Even if you could capture a proposed deletion before save, which AFAIK you can't, you will still have an undo mess. IMHO you best bet is to capture the situation at the point of editing the predicate, substituting the deleted item with a placeholder like "<deleted>".
I agree, trying to capture the deletion would be an unholy mess.
But perhaps I haven't explained the problem clearly enough. The problem arises not when the predicate is being edited, but when entity referenced in the predicate is deleted. I need to find a way to notice this and then to take corrective action.
Also, it would be nice to let the user know that the deletion of this entity will invalidate a SmartGroup. Once the model is changed appropriately I can perform this check in response to the user request to delete the entity.
>
> HTH,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
_______________________________________________
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