refreshObject:mergeChanges: vs. stale transient properties
refreshObject:mergeChanges: vs. stale transient properties
- Subject: refreshObject:mergeChanges: vs. stale transient properties
- From: Jim Correia <email@hidden>
- Date: Mon, 8 Aug 2005 15:32:04 -0400
I have an app which is using more than one managed object context on
the same persistent store.
The documentation for refreshObject:mergeChanges: says
- (void)refreshObject:(NSManagedObject *)object mergeChanges:
(BOOL)flag
Updates the persistent properties of object to use the latest
values
from the persistent store. If the staleness interval has not been
exceeded, any available cached data will be reused instead of
issuing a
new fetch. If flag is YES, merges the current state of object
with the
state of the object available in the persistent store
coordinator; if
flag is NO, simply refaults an object without merging. If flag
is YES,
this method does not affect any transient properties; if flag is
NO,
transient properties are released.
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? (I can write
specific code which looks at the objects in the updatedObjects list
and takes appropriate action based on the entity kind, but I was
hoping for a more general solution.)
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