couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: conflict determination not by fields
Date Mon, 29 Aug 2011 16:28:54 GMT
There is no general approach for resolving conflicts that will work in
all use cases. Or even a majority of use cases. Even diff/patch
merging requires users to resolve their own conflicts (when it can
even detect the conflict). This isn't something that can be done

On Mon, Aug 29, 2011 at 11:03 AM, gaoyong pan <> wrote:
> The way of "diff" and "patch" sounds a general approach, is it
> possible make this just a built-in capability for couchDB, a general
> json diff/patch support. CouchDB has revision numbers for a document,
> I don't know how this works internally, does it save the diff or the
> whole document for each revision, if it saves the diff, then it might
> also use the diff to produce next revision of the same document.
> 2011/8/29 Victor Nicollet <>:
>> Hello,
>> There are ways. One of them would be to store each object as multiple
>> timestamped insert-only "diff" documents ("on August 29, I set the phone
>> number to XXX") and have a reduce operation merge those documents into a
>> single object. If you use UUIDs for your documents, then replication will
>> not create any conflicts. Optionally, you may then cache the result of the
>> reduce operation back to the database (you need to do so 1. for the modified
>> object whenever you create a new diff document and 2. for the conflicted
>> objects whenever you replicate) so that you may improve query performance
>> and use those objects in views.
>> Another way would be to store every field of your objects in a different
>> document, with an identifier like _id + "-phone", so conflicts would only
>> happen if you alter the same field of the same object on two different
>> devices. You can query all data for an object using a simple map (no reduce
>> needed this time), and you can cache the result of that query as a document
>> using the same caching rules as above.
>> Then again, I believe you might be overestimating the difficulty of handling
>> conflicts. Once you sync, fetching three revisions of all conflicted
>> documents, running the trivial merge function you seem to describe, and
>> writing the merged document back to the database is a very simple operation.
>> -- VN
>> On 29 August 2011 07:05, gaoyong pan <> wrote:
>>> If so, let's suppose that we have an application address book, one UI
>>> is web-based and another mobile native application, people may edit
>>> his own address book either on web or device, 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.
>>> Is there any such kind of DB make really app relax?
>>> 2011/8/29 Jens Alfke <>:
>>> >
>>> > On Aug 28, 2011, at 9:02 PM, gaoyong pan wrote:
>>> >
>>> > I updated the same document in two previously replicated and identical
>>> > DB, by updating two different fields, after replication, they are in
>>> > conflicted status, I want to know if this is a bug of couchdb?
>>> >
>>> > No, that’s correct behavior. You made different changes to each instance
>>> of the document, so now they are in conflict. CouchDB doesn’t try to merge
>>> individual fields in a document; it leaves that up to you (because it often
>>> requires app-specific logic to do properly.)
>>> >
>>> > —Jens
>>> >
>>> --
>>> Pan
> --
> Best Regards
> Linux user #384184
> @

View raw message