Re: refreshObject:mergeChanges: vs. stale transient properties
Re: refreshObject:mergeChanges: vs. stale transient properties
- Subject: Re: refreshObject:mergeChanges: vs. stale transient properties
- From: mmalcolm crawford <email@hidden>
- Date: Tue, 9 Aug 2005 17:09:58 -0700
On Aug 9, 2005, at 8:23 AM, Jim Correia wrote:
On Aug 8, 2005, at 9:10 PM, Jim Correia wrote:
I've read that. Transient properties aren't cleared if
mergeChanges is YES (which I need so that I don't wipe out
committed but unsaved changes in the target context.) The
transient property appears to be nil at this point, but I think
that is just an illusion for the life of the method. If I call
[self setPrimitiveValue: nil forKey: @"myTransientCachedProperty"]
it doesn't seem to have any affect.
It does have an effect, however the cached values are applied *after*
didTurnIntoFault/awakeFromFetch, so anything you update there will be
replaced by the cached value.
Unfortunately, there isn't any other way to register a dependency of
a transient value on a value that may be refreshed (and it's not
entirely clear that there would be a generic solution that would work
with all possible custom implementations of transient properties), so...
The cached value is used on the next accessor invocation (I've
stepped through it.)
Any further advice or hints?
What I ended up doing was, since I couldn't clear the transient
attribute in didTurnIntoFault, was to simply set a flag that the
attribute is stale and should be recomputed.
... this is as good an implementation as you're likely to get.
Please file a documentation bug to ensure this is clarified.
mmalc
_______________________________________________
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