Re: Analyzing Core Data Conflict List
Re: Analyzing Core Data Conflict List
- Subject: Re: Analyzing Core Data Conflict List
- From: Ben Trumbull <email@hidden>
- Date: Tue, 3 Feb 2009 13:42:14 -0800
You may also wish to refresh the objects more frequently. The larger
the staleness interval the more likely an optimistic locking
exception
will occur due to a large window for simultaneous edits.
Is that as simple as just decreasing the ManagedObjectContext's
staleness interval? I do that temporarily when calling
refreshObject. Perhaps I should just keep it short. I recall
your comment last year that a very short staleness interval can
reveal a minor Core Data refreshObject bug.
If the staleness internal is smaller than the server's latency, it can
cause performance problems as the rows become stale before they get
used and get refetched.
One easy way to do this is to use a fetch request with prefetching
for
the related objects most likely to change.
For better or worse, our application rarely does programatic
fetches. Instead, it makes heavy use of NSArrayControllers. We
do some in-memory filtering using mmalc's excellent
FilteringController technique -- but very little overt
fetching. Is there a way to prefetch in that scenario? I
suppose NSArrayController might have an NSFetchRequest to which
I could add prefetching keys, but I can't see how to get at it.
You can use a subclass of NSArrayController to configure all the fetch
request options. The methods to override and then call super are
declared at the bottom of NSObjectController.h
- Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden