On Aug 28, 2011, at 10:05 PM, gaoyong pan wrote: > I thought the > application may take the relax approach and don't worry about the DB > in-sync issue for this distributed application, when device is > connected through wifi, the db is sync'ed automatically, but actually > this is not true, the app has to handle the conflict in application > level.
There’s not really any way around this, in general. Conflicts are part of the app’s design and can’t be resolved at the database layer. Almost any nontrivial app is going to have to manage conflict resolution. This isn’t specific to CouchDB; it applies to any system that uses optimistic concurrency. Actually you _will_ see that the database is synced automatically without intervention; what will happen is that it will choose one of the two conflicting documents as the ‘winner’ and use that one. So you’re not forced to resolve the conflict, if that approach is good enough for your app. What you’re asking for is one step more detailed: merging individual fields together. The problem is that, depending on the document’s schema, this can cause data loss or corrupted documents. In your address book example, let’s say the ‘phone’ field is an array of strings containing phone numbers. What happens if two clients each add a different phone number? Updating the ‘phone’ field to one array or the other will lose one of the phone numbers. OK, so maybe we make the algorithm more complex and recurse into sub-fields, creating a union of arrays. That works OK, unless perhaps the order of the items in the array matters (maybe it’s always ordered work, home, mobile?). Or what if the user _deletes_ a phone number on one side — how do you merge the arrays then? So since this is a slippery slope, and there’s no approach that works for everyone, CouchDB takes the approach of “do the simplest thing that could possibly work” and that doesn’t lose or corrupt data. Namely, it chooses one of the documents, but keeps the others around so you can do fine-grained merging yourself. —Jens
