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: Mon, 8 Aug 2005 21:10:32 -0400
On Aug 8, 2005, at 6:03 PM, mmalcolm crawford wrote:
On Aug 8, 2005, at 12:32 PM, Jim Correia wrote:
When a managed object context is saved, I sync the the other ones
by faulting the objects with refreshObject:mergeChanges:.
If I pass NO for mergeChanges, then committed but unsaved edits in
the target context are lost, so I'm passing YES.
That is the gotcha - if you pass YES the transient properties are
unaffected. But I have a transient property which is the cached
decoded value of a binary attribute. If that attribute was the one
which was saved in the alternate context, my transient property is
now stale and needs to be relcalculated.
What is the recommended way to handle this situation?
<http://developer.apple.com/documentation/Cocoa/Reference/
CoreData_ObjC/Classes/NSManagedObject.html#//apple_ref/doc/uid/
TP30001171-BBCCEDDC>
Malcolm,
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?
Thanks,
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