I want my app to access the new value of an object's property stored in an
sqlite store, after this value has been modified on disk by another process.
A few weeks ago, I did this, and I thought it was working:
[[obj managedObjectContext] refreshObject:self
mergeChanges:YES] ;
id foo = [obj foo] ;
However, upon retesting today I found that foo was the old value, and after
puzzling over the documentation of -[NSManagedObject
refreshObject:mergeChanges:], and some experimentation, I fixed it by doing
this instead:
[[obj managedObjectContext] processPendingChanges] ; // just in case
NSTimeInterval oldStaleness = [[obj managedObjectContext]
stalenessInterval] ;
[[obj managedObjectContext] setStalenessInterval:0.0] ;
[[obj managedObjectContext] refreshObject:self
mergeChanges:NO] ;
id foo = [obj foo] ;
[[obj managedObjectContext] setStalenessInterval:oldStaleness] ;
By the way, oldStaleness is the default value of -1.0.
Is there a better way?
It seems like "gimme the latest value of object.foo from the disk" shouldn't be
so hard. If all you read is the first line of that documentation [1], you
think that it is easy!
Thanks,
Jerry Krinock
[1] NSManagedObject
• refreshObject:mergeChanges:
Updates the persistent properties of a managed object to use the latest values
from the persistent store.
- (void)refreshObject:(NSManagedObject *)object mergeChanges:(BOOL)flag
If flag is NO, then object is turned into a fault and any pending changes are
lost. The object remains a fault until it is accessed again, at which time its
property values will be reloaded from the store or last cached state.
If flag is YES, then object’s property values are reloaded from the values from
the store or the last cached state then any changes that were made (in the
local context) are re-applied over those (now newly updated) values. (Ifflag is
YES the merge of the values into object will always succeed—in this case there
is therefore no such thing as a “merge conflict” or a merge that is not
possible.)
Discussion
If the staleness interval (see stalenessInterval) has not been exceeded, any
available cached data is reused instead of executing a new fetch. If flag is
YES, this method does not affect any transient properties; if flag is NO,
transient properties are released.
You typically use this method to ensure data freshness if more than one managed
object context may use the same persistent store simultaneously, in particular
if you get an optimistic locking failure when attempting to save.
It is important to note that turning object into a fault (flag is NO) also
causes related managed objects (that is, those to which object has a reference)
to be released, so you can also use this method to trim a portion of your
object graph you want to constrain memory usage.
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
