Re: Analyzing Core Data Conflict List

2009-02-03 Thread Steve Steinitz
Hi Ben, Oops, I omitted some key information in the previous message... We wrote: Here's what I added to awakeFromNib in my NSArrayController subclass: [request setRelationshipKeyPathsForPrefetching: [NSArray arrayWithObjects: @"customer", @"salesPerson", @"payments", @"lineItems", @"bikes",

Re: Analyzing Core Data Conflict List

2009-02-03 Thread Ben Trumbull
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

Re: Analyzing Core Data Conflict List

2009-01-30 Thread Steve Steinitz
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 lik

Re: Analyzing Core Data Conflict List [was: Formatting Core Data Conflict List]

2009-01-30 Thread Ben Trumbull
On Jan 29, 2009, at 11:51 PM, Steve Steinitz wrote: The newVersion and oldVersion shows the version count on the objects really has changed. OK, that makes reading the coflict list clearer. So that version count is an ever-incrementing number -- as long as the app is running? For atomic