Re: refreshObject:mergeChanges: vs. stale transient properties
Re: refreshObject:mergeChanges: vs. stale transient properties
- Subject: Re: refreshObject:mergeChanges: vs. stale transient properties
- From: Jim Correia <email@hidden>
- Date: Tue, 9 Aug 2005 11:23:41 -0400
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.
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.
- (void)didTurnIntoFault
{
transientValueStale = YES;
[super didTurnIntoFault];
}
- (id)transientValue
{
id transientValue = nil;
if (! transientValueStale)
{
// fetch transient value
}
if (transientValue == nil)
{
// recompute transient value from persistent value
}
transientValueStale = NO;
return transientValue;
}
If there is a better or more correct solution, I'm all ears, but this
seems to solve the immediate problem.
Jim
_______________________________________________
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