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: Sat, 18 Feb 2006 00:10:25 -0800
On 平成 18/02/17, at 22:46, Chris Hanson wrote:
On Feb 17, 2006, at 8:24 PM, Andre wrote:
Thanks, I guess I could do that then. I was just worried that if I
have a huge number of 'employee' entities, then performance could
degrade... is that a concern at all?
I wouldn't worry about it. Especially with the kind of fetch I
used above and the SQLite persistent store, you should really let
the Core Data persistence stack do the heavy lifting for you. That
can mean leveraging fetch requests for filtering rather than
strictly measuring
Ok.
Hmm, I'm wondering, if I retrieve a set of objects using KVC for a
relation like [engineering mutableSetValueForKey:@"employees"]
does it use the same mechanism as the fetch predicate like in your
example : (department = %@), with coredata knowing 'department' is
an to-many relationship... so the performance is the same? (I know
we shouldn't rely too much on implementation details as they
change, but its more for performance question)
Indeed, you shouldn't rely too much on implementation details. If
you want to work with the objects in the relationship as objects in
a relationship, you should use the relationship. If you want to
work with objects meeting some criteria, even objects in a
relationship, using a fetch request rather than doing the filtering
yourself can make things easier and it can be easier for the
framework to support you in your use. Your best bet is to always
try to follow the framework's patterns first, and reserve
performance optimization and doing things "by hand" for the areas
where measurement shows it's necessary.
Also, I know you wanted to avoid normalizing your data model such
that your large data BLOB is in a separate entity, but you really
should consider it. You can put a transient BLOB attribute on its
"owner" that traverses the relationship upon access, and avoid
pulling the BLOB data in from the persistent store any time you
don't actually need to use it. (Assuming again you're using the
SQLite persistent store type.)
Thanks for the patient answer.
In any case, I'll follow your suggestion, and I'm also going to file
an enhancement request for per-column/attribute faulting, so that
when calling a specific attribute, only its attribute is un-faulted,
instead of all the attributes... this is something that some RDB
support, and it shouldn't be too hart to implement at the object
level I would think? 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.
Well, in any case, look forward to what you guys do with CD 2.0....
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