Re: Analyzing Core Data Conflict List [was: Formatting Core Data Conflict List]
Re: Analyzing Core Data Conflict List [was: Formatting Core Data Conflict List]
- Subject: Re: Analyzing Core Data Conflict List [was: Formatting Core Data Conflict List]
- From: Ben Trumbull <email@hidden>
- Date: Fri, 30 Jan 2009 00:07:12 -0800
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 stores, yes. For the SQLite store, it is persisted.
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 :)
objectTrump is probably best.
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.
For something like a Sale < - >> lineItem scenario, whenever you add
or remove to the set of lineItems, the Sale object is dirtied.
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. But for multiple users on large rapidly changing
relationships, maintaining the relationships formally might be more
expense than it's worth.
That said, can you clarify (a) 'dirtying transients' a little or
point me to some doco?
If you have a transient property, calling a setter on it will make the
object think it's been dirtied for the next save.
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. One easy way
to do this is to use a fetch request with prefetching for the related
objects most likely to change.
- 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