• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa-dev Digest, Vol 7, Issue 777
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa-dev Digest, Vol 7, Issue 777


  • Subject: Re: Cocoa-dev Digest, Vol 7, Issue 777
  • From: Keary Suska <email@hidden>
  • Date: Fri, 30 Jul 2010 08:13:46 -0600

On Jul 29, 2010, at 5:59 PM, Martin Stanley wrote:

>> 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.

I was assuming that your language use was loose, but do you *really* mean deleting an entity, or simply deleting a managed object of that entity type? The former would be a horribly bad idea in most cases.

Assuming that you don't mean the above, I still don't think you are articulating the problem correctly. Deleting isn't the problem--Core data does that just fine. It seems that it is some *consequence* of the deletion that is the problem. What is that precisely? That a "smart group" will be invalid? Unless you present it otherwise to the user, it is just a predicate, and it is just as valid if it doesn't match anything.

But then if the problem is that you don't want this condition to occur without user consent--which may be a friendly feature--as long as project objects can't be deleted by core data internal processes (such as the result of a delete rule), you have complete control over the deletion, so you can check it then, before it even occurs.

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

  • Follow-Ups:
    • Re: Intercepting deletion of NSManagedObjects or how to handle deletion in non-explicit relationships?
      • From: Martin Stanley <email@hidden>
References: 
 >Re: Cocoa-dev Digest, Vol 7, Issue 777 (From: Martin Stanley <email@hidden>)

  • Prev by Date: [ANN] JSONKit - Yet another JSON library
  • Next by Date: IKImageView choppy?
  • Previous by thread: Re: Cocoa-dev Digest, Vol 7, Issue 777
  • Next by thread: Re: Intercepting deletion of NSManagedObjects or how to handle deletion in non-explicit relationships?
  • Index(es):
    • Date
    • Thread