Re: When exactly does a fault get fired?
Re: When exactly does a fault get fired?
- Subject: Re: When exactly does a fault get fired?
- From: Andre <email@hidden>
- Date: Sun, 19 Feb 2006 00:22:39 -0800
Chris Hanson wrote:
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.
Yes, I understand. I guess I'm just stubborn about my model.... I
just like to have it a simple (perhaps too simple) as possible. I've
learned a lot though, and this has actually been a very good
experience even though I didn't "get the answer I wanted" I still
"got what I wanted" so yea its all good.
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.
Yes. I'm doing this now. Its going to be fine I think. Its reaaaly
hard to fight the pre-mature optimization reflex. (!)
But, "like obj-c messaging is too slow so I'll use pure C" argument
(I used to believe this unfortunately), I'll learn to trust core
data more.
Thanks a lot, really.
Sincerely,
Andre
email@hidden
_______________________________________________
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