couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <>
Subject Re: conflict determination not by fields
Date Mon, 29 Aug 2011 16:34:01 GMT

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.

View raw message