couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Victor Nicollet <>
Subject Re: conflict determination not by fields
Date Mon, 29 Aug 2011 09:12:55 GMT

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message