Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.hirst@sophos.com
 designates 216.47.234.213 as permitted sender)
From: Paul Hirst <paul.hirst@sophos.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Wed, 18 Apr 2012 09:51:27 +0100
Subject: Making conflicts first class citizens
Thread-Topic: Making conflicts first class citizens
Thread-Index: Ac0dQHEXjbqEn+hEQOmt45DQwxGXvA==
Message-ID: 
 <36E79CEC5BFB8E4D9763C4DEB9B1163C38B418CEB1@UK-EXCHMBX1.green.sophos>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative;
	boundary="_000_36E79CEC5BFB8E4D9763C4DEB9B1163C38B418CEB1UKEXCHMBX1gre_"
MIME-Version: 1.0

--_000_36E79CEC5BFB8E4D9763C4DEB9B1163C38B418CEB1UKEXCHMBX1gre_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I saw this idea on allourideas.org:

"Conflicts as first class citizens: Surface the conflict on read, and alway=
s accept a write, assuming it passes validation."

I was wondering if anyone could expand on this?

On write, conflicts will be rejected at the moment which is really handy fr=
om a simplicity point of view and in many use cases it's a good enough solu=
tion. If you use the all_or_nothing:true option through the bulk API then y=
ou can currently write conflicting documents and this is (as I understand i=
t) exactly what replication does.

So, is this idea, about changing the default behaviour to act as the all_or=
_nothing option? Does it get rid of the ability to detect and reject confli=
cts at write time? Lastly, why does anyone want it when we seem to have the=
 best of both worlds at the moment?

________________________________
Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, Un=
ited Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.

--_000_36E79CEC5BFB8E4D9763C4DEB9B1163C38B418CEB1UKEXCHMBX1gre_--