• 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: When exactly does a fault get fired?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When exactly does a fault get fired?


  • Subject: Re: When exactly does a fault get fired?
  • From: Chris Hanson <email@hidden>
  • Date: Sat, 18 Feb 2006 00:42:38 -0800

On Feb 18, 2006, at 12:10 AM, Andre wrote:

Thats sort of what I was trying to do: sort of be able to pull an attribute value without firing a fault by implementing my own cache (of a text value)... then the matching BLOB can be retrieved and fire the fault.... that was my original goal anyways.

That's actually what normalizing your model is all about. The difference is that it lets Core Data do the work of maintaining that kind of cache for you (and leveraging its knowledge of your model to do so efficiently too). For example, say you have a system where you're working with Article entities. You might initially model this as:


  Article {
    title: required string;
    date: required date;
    formattedText: required binary data;
  }

Any time you show an Article's title, you'll also be getting its formatted text. If you're not doing anything with the text at the same time, but you're paying for its retrieval, that can be an indicator that it might be better off apart of the Article object. That in turn could lead you to this modeling:

  Article {
    title: required string;
    date: required date;
    formattedText: transient binary data;
    articleText: required to-one to ArticleText with
                 inverse article, on delete cascade;
  }

  ArticleText {
    formattedText: required binary data;
    article: to-one to Article with inverse
             articleText, on delete nullify;
  }

You could implement a managed object class for Article and in the accessor for its formattedText transient attribute, actually have it manipulate the formatted text in the associated ArticleText. This gets you effectively the best of both worlds: You only pay for fetching the text when you access it, and you still have something that looks like direct access to the text to the users of Article.

Thus the transient attribute and its accessor, the normalized entity, and the relationship to it from the original entity do the same thing as a manually-maintained cache but in fashion that's transparent to client code.

  -- Chris

_______________________________________________
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: When exactly does a fault get fired?
      • From: Andre <email@hidden>
References: 
 >When exactly does a fault get fired? (From: email@hidden)
 >Re: When exactly does a fault get fired? (From: AurĂ©lien HugelĂ© <email@hidden>)
 >Re: When exactly does a fault get fired? (From: Andre <email@hidden>)
 >Re: When exactly does a fault get fired? (From: Chris Hanson <email@hidden>)
 >Re: When exactly does a fault get fired? (From: mmalcolm crawford <email@hidden>)
 >Re: When exactly does a fault get fired? (From: email@hidden)
 >Re: When exactly does a fault get fired? (From: Chris Hanson <email@hidden>)
 >Re: When exactly does a fault get fired? (From: Andre <email@hidden>)
 >Re: When exactly does a fault get fired? (From: Chris Hanson <email@hidden>)
 >Re: When exactly does a fault get fired? (From: Andre <email@hidden>)

  • Prev by Date: Re: When exactly does a fault get fired?
  • Next by Date: Re: Buld and running the simplest things fail...
  • Previous by thread: Re: When exactly does a fault get fired?
  • Next by thread: Re: When exactly does a fault get fired?
  • Index(es):
    • Date
    • Thread