Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4AF6688F.2070103@vcardprocessor.com>
Date: Sun, 08 Nov 2009 12:13:27 +0530
From: ericdes <eric@vcardprocessor.com>
Reply-To: eric@vcardprocessor.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: What happens with a document, if a conflict is not resolved?
References: <01E98E17-B6AF-4F2F-9752-23CE46D51336@apache.org>
 <20091031104043.GA12386@uk.tiscali.com>
 <20091101115359.GA11480@uk.tiscali.com>
In-Reply-To: <20091101115359.GA11480@uk.tiscali.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Brian,

I read your posts about conflicts with great interest. I'm currently 
writing a .Net driver for CouchDB, and my point of view about making the 
default GET include all conflicts is that it is not a bad idea at all 
(even ideal), although a driver implementation may 'hide' that by 
implementing a GetDocument method that would add the query option by 
default.

I think it's more annoying not to have the possibility of using the 
conflict query 'conflicts=true' when requesting multiple documents (I 
mean especially when you don't want to include the docs). For example, 
this could be used by a CouchDB explorer type application that would 
retrieve all record metadata and signal the conflicts with a specific 
icon (like tortoise SVN does when a document is out of sync for example).

Eric Desgranges.


On 11/1/2009 5:23 PM, Brian Candler wrote:
> On Sat, Oct 31, 2009 at 10:40:43AM +0000, Brian Candler wrote:
>>> I think I'd be in favor of making the default GET include all conflicts,
>>> but probably in the _conflicts field so as to minimize the changes to the
>>> current API.
>>
>> As a first step, that would be unlikely to break anyone, would make it clear
>> when a conflict exists, and would simplify the API by removing the need for
>> ?conflicts=true. So I'd vote for that.
>
> Also: if you query a view with ?include_docs=true, at the moment you never
> get a _conflicts member in the document, even if you say
> ?include_docs=true&conflicts=true
>
> Perhaps you should?
>
> B.
>