Analyzing Core Data Conflict List [was: Formatting Core Data Conflict List]
Analyzing Core Data Conflict List [was: Formatting Core Data Conflict List]
- Subject: Analyzing Core Data Conflict List [was: Formatting Core Data Conflict List]
- From: Steve Steinitz <email@hidden>
- Date: Fri, 30 Jan 2009 18:51:30 +1100
Hi Ben,
Thanks for your helpful reply.
On 29/1/09, Ben Trumbull wrote:
It's just an array of dictionaries with a fixed set of keys.
Ah, yes, I can see that now -- the familiar logging format.
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?
A few things to note. First, you've set a merge policy on the
NSManagedObjectContext right ?
Yes, its currently objectTrump. I vacillate between that and
StoreTrump, switching whenever my level of panic clips. I'm
thinking of trying 'Overwrite' just for fun (my client might not
think its so fun :)
Some sources of conflicts that surprise people are (a) dirtying
transients, (b) maintaining last mod timestamps (c) making
blind changes in -willSave or validation callbacks, or (d)
updating the contents of a to-many relationship.
Great list, thanks. Pouring over the conflict list, I'm
suspicious of (d) '...to-many relationship' which happens to
lots of objects (because of event logging, customer history etc)
whenever my client creates a sale or adds a lineItem. That
said, can you clarify (a) 'dirtying transients' a little or
point me to some doco?
Thanks again, Ben.
Best regards,
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