incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
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
automatically.

On Mon, Aug 29, 2011 at 11:03 AM, gaoyong pan <pan.gaoyong@gmail.com> 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 <vnicollet@runorg.com>:
>> 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 <pan.gaoyong@gmail.com> 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 <jens@couchbase.com>:
>>> >
>>> > 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
> @ http://counter.li.org/
>

Mime
View raw message