• 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: CoreData faulting - does it rely on #self?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData faulting - does it rely on #self?


  • Subject: Re: CoreData faulting - does it rely on #self?
  • From: Todd Blanchard <email@hidden>
  • Date: Fri, 14 Apr 2006 13:35:16 -0700


On Apr 13, 2006, at 1:37 PM, Jim Correia wrote:

Is there a reason you couldn't use the existing method for that purpose, without supplying a new one in a category?

I think when I started this - self wasn't there - pre -10.4. I'm not sure but I suspect it was added with CoreData.


So I've removed it. I still keep setSelf: because if you bind on self (like in a table), the controller will eventually call setSelf: and all manner of bad things happen.

It doesn't appear that NSManagedObject overrides self in today's framework. What we do know is that it is documented that you shouldn't override that method. If you do, even if it works on 10.4.x, there's no guarantee that a) it will in a future OS release and b) that anyone will care if your app breaks because you explicitly did what the documentation said not do to.

Which leaves me wondering how to explicitly trigger faults in a generic way. My app requires all objects in memory at all times - faulting I'm not ever interested in. When the file is opened I want it all read in right now. To do this In EOF, you just called self on everything you suspected might be a fault.


My other concern is whether saving turns everything back into a fault.

AFAICT, saving is not documented as turning objects into faults. In my experience, it does not have that side effect.

I'm seeing a little notification storm during saving where many attributes are set to nil. Its messing me up big time. I now override save to remove all my observers from the objects prior to saving, then put them back. This helps a lot but I don't think it should be necessary.


-didTurnIntoFault is invoked automatically when an object is turned into a fault. I think you'll find that trying to fire the fault from within this method will be unsuccessful. (I don't remember the exact failure case - this was only happening as the result of a bug which I've long since fixed.)

I guess I'll have to add them to a list and re-trigger them sometime later. It would be really nice if there was a little flag called NO_BLOODY_FAULTING_EVER or something. The precise semantics of faulting behavior matter a lot in my case and they are not well documented.


-Todd Blanchard

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: CoreData faulting - does it rely on #self?
      • From: Todd Blanchard <email@hidden>
    • Re: CoreData faulting - does it rely on #self?
      • From: mmalcolm crawford <email@hidden>
References: 
 >Re: CoreData faulting - does it rely on #self? (From: Greg Herlihy <email@hidden>)
 >Re: CoreData faulting - does it rely on #self? (From: Todd Blanchard <email@hidden>)
 >Re: CoreData faulting - does it rely on #self? (From: Jim Correia <email@hidden>)

  • Prev by Date: Re: NSOpenPanel / trigger and edit fields
  • Next by Date: Randomize records in a table view
  • Previous by thread: Re: CoreData faulting - does it rely on #self?
  • Next by thread: Re: CoreData faulting - does it rely on #self?
  • Index(es):
    • Date
    • Thread