Core Data conflict detection
Core Data conflict detection
- Subject: Core Data conflict detection
- From: Paulo Andrade <email@hidden>
- Date: Mon, 19 Jul 2010 14:04:55 +0100
Hello,
I'm trying to get my head around how Core Data handles optimistic locking failures but still haven't figured this out.
This discussion is purely conceptual, I have no sample code to back my assumptions, its purpose is to clarify what should happen in various scenarios.
Core Data uses snapshots to detect conflicts. When saving a dirty object, if the values on the snapshot for that object are different than those on the persistent store you have a conflict.
However, the mechanism that makes this work is not explained. Leading me to the following questions.
Problem 1: Detecting conflicts on stores other than SQL
For the SQLStore it's is easy to imagine that an update to an object as a "WHERE" clause referencing the previous values from the snapshot, similarly to what EOF does.
It doesn't really matter exactly how Core Data does this but one must create a mental model. (From the little SQLDebug statements I've seen, I'm guessing that Core Data uses the private "Z_OPT" field to keep a version of the tuple on the database and uses this for optimistic locking… this is pure guessing).
But how does this work for the XMLStore? Or custom stores using the NSAtomicStore? Is the file re-read to see if it is changed? (Note that there is no Z_OPT here, so there must be another way)
Since Core Data isn't supposed to be used in cases where the underlying file changes beneath it (ie, multiple applications accessing the same file) this isn't really a problem. If that Core Data application is the only one reading and writing to that file this scenario should not happen.
Leading me to believe conflict detection is made higher up on the stack. Jump to the next problem.
Problem 2: Concurrency
This problem has mainly to do with snapshots, where they are stored and with what they are compared with when saving.
Imagine this scenario:
You have two threads (T1 and T2) each with their own managed object context (moc1 and moc2) which use the same persistent store coordinator.
1 - T1 reads ObjectX
<the snapshot for ObjectX is created>
2 - T2 reads ObjectX
3 - T1 makes some changes to ObjectX
4 - T2 makes some other changes to ObjectX and saves
< at this point the snapshot should be updated >
5 - T1 tries to save
I'm expecting a conflict after point 5. But what does Core Data use to know this? If the snapshot is updated with the new value at step 4, the snapshot values are equal to what is on the persistent store.
Show does "Core Data" know there is a conflict?
And who owns the snapshots? Is it NSPersistentStore, NSPersistentStoreCoordinator or the NSManagedObjectContext?
I'm hoping I've been clear and this will lead to a healthy discussion on the intricacies of conflict detection.
Best regards,
Paulo Andrade
_______________________________________________
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