• 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: Observing Managed Object Changes. Was: Strange ... behavior
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Observing Managed Object Changes. Was: Strange ... behavior


  • Subject: Re: Observing Managed Object Changes. Was: Strange ... behavior
  • From: Quincey Morris <email@hidden>
  • Date: Wed, 25 Feb 2009 11:24:28 -0800

On Feb 25, 2009, at 05:31, Jerry Krinock wrote:

On 2009 Feb 24, at 20:02, Dave Fernandes wrote:

... I'm only just getting familiar with the idiosyncrasies of Leopard, however, in Tiger didTurnIntoFault might be called many times, but awakeFromInsert or awakeFromFetch was only called once for the lifetime of the MOC (not the lifetime of the object). Thus, if you delete the object, and then undo that action, your observers will be removed by didTurnIntoFault and not added back since awakeFromFetch is not called again.

...

*  Using KVO is no good because observers must be removed before an
    object becomes a fault, and there is no mechanism to find out
    when the object un-becomes a fault, which you need to restore
    your observers.

I'm not making any absolute assertions here, but this doesn't seem right to me. If 'awakeFromFetch' isn't called when an object is faulted in, then transient properties (for example) could never be worth a damn. I couldn't see anything in the documentation that *explicitly* says that 'awakeFromFetch' is called in these circumstances, but nothing else makes any sense.


Dave's earlier comment on this contains some assumptions that are suspect. I don't know of any guarantee that deleting an object causes the object to first be faulted out and/or to receive a 'didTurnIntoFault' message, but perhaps it's so, or perhaps it's a current implementation detail that can't be relied on in the future. Further, I wouldn't expect 'awakeFromFetch' to be called as a result of undo. I might expect 'awakeFromInsert' to be called as a result of undoing a deletion, but, given Core Data undo's overall inscrutability, it's possible that it just restores the previous MOC state directly, without invoking the various supporting "notification" methods. (Undo does, for example, restore the values of transient properties, so *that* reason for needing some kind of 'awakeFrom...' is obviated.)


_______________________________________________

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: Observing Managed Object Changes. Was: Strange ... behavior
      • From: Dave Fernandes <email@hidden>
    • Re: Observing Managed Object Changes. Was: Strange ... behavior
      • From: Jerry Krinock <email@hidden>
References: 
 >Strange NSManagedObjectContextObjectsDidChangeNotification behavior (From: Karolis Ramanauskas <email@hidden>)
 >Re: Strange NSManagedObjectContextObjectsDidChangeNotification behavior (From: Jerry Krinock <email@hidden>)
 >Re: Strange NSManagedObjectContextObjectsDidChangeNotification behavior (From: Dave Fernandes <email@hidden>)
 >Observing Managed Object Changes. Was: Strange ... behavior (From: Jerry Krinock <email@hidden>)

  • Prev by Date: Re: NSTableView Cell edit values.
  • Next by Date: Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
  • Previous by thread: Observing Managed Object Changes. Was: Strange ... behavior
  • Next by thread: Re: Observing Managed Object Changes. Was: Strange ... behavior
  • Index(es):
    • Date
    • Thread