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: Aurélien Hugelé <email@hidden>
- Date: Fri, 17 Feb 2006 10:33:31 +0100
it is the willAccessValueForKey that fire the fault. Default
NSManagedObject -valueForKey: implementation does call
willAccessValueForKey: for you.
Just one warning, i do not know what your needs are, but core data
already accesses a sort of cache when your access an attribute.
Having another cache above it is memory over use(because of your
cache, the core data cache for this attribute may not be released),
and maybe even dangerous (both cache needs to be synchronized, it can
be complex).
I'm pretty sure that you want to use your own cache because you have
problems with fault firing performances/core data performances, i had
a lot of problems too. It may be interesting you explain *why* would
you want to use your own cache mechanism.
I say it again, i do not know your needs, and you may have good
reasons! :)
Aurelien
On 17 févr. 06, at 09:51, email@hidden wrote:
Hi, list, I've got a question concerning faults in core data.
If an entity has a attribute that is in the data model and has an
accessor for it, when a call to the accessor occurs, does the fault
fire exactly when the call [object valueForKey:@"Key"] gets sent,
or, in the custom method, does the fault stay un-fired until I call
[self willAccessValueForKey:@"Key"] or [self
primitiveValueForKey:@""]....
I'm asking because I would like to cache a value without doing a
separate accessor, so I'm wondering if I can return the cache if it
exists instead...without fire a fault (thats the reason why I want
to use a cache)....
Thanks in advance!
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:
40gumitech.com
This email sent to 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