Re: Analyzing Core Data Conflict List
Re: Analyzing Core Data Conflict List
- Subject: Re: Analyzing Core Data Conflict List
- From: Steve Steinitz <email@hidden>
- Date: Sat, 31 Jan 2009 00:34:35 +1100
Hi Ben,
Thanks for your reply. I've made some comments and asked a
couple questions. In particular please see the one (at the end)
about prefetching in an NSArrayController scenario.
On 30/1/09, Ben Trumbull wrote:
While we strongly discourage using no inverse relationships, something
like event logging might be a place to consider it. So you might model
AuditTrail < - 0 Events
so you would code the to-many side on AuditTrail with a fetch request
using a predicate like "auditRelationship = %@" where the vararg is
AuditTrail's objectID.
It would be your responsible to ensure all the Events get deleted
properly, and you'll miss out on some validation checking without the
inverse. You also won't get support from the merge policies for
conflict detection.
Great 'heads-ups", thanks.
for multiple users on large rapidly changing relationships,
maintaining the relationships formally might be more expense than it's
worth.
That's interesting. An error in our 'Audit Trail' wouldn't be a
big problem. We call it an 'Exposure Log' because it only logs
suspicious activity. We don't expect it to be a complete audit
trail. So maybe I could remove the to-many inverse
relationships from Sales and Employees, as long as removing them
didn't result in a corrupt database i.e. "can't fulfill fault".
On the other hand, we'd lose convenience in displaying the
Exposure Log. Maybe I'll keep that up my sleeve for later.
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.
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.
Thanks again,
Steve
_______________________________________________
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