Re: refreshObject:mergeChanges: vs. stale transient
Re: refreshObject:mergeChanges: vs. stale transient
- Subject: Re: refreshObject:mergeChanges: vs. stale transient
- From: Frank Illenberger <email@hidden>
- Date: Tue, 9 Aug 2005 11:37:29 +0200
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?
Jim,
as I see it, when a managed object is refreshed, it is first turned
into a fault. It you can flush your transient attributes in
didTurnIntoFault: you should have the behavior you want.
Frank
_______________________________________________
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