In my opinion, and I believe the majority opinion of the group, the
CouchDB API should be the same everywhere. This specifically includes
not doing things on a single box that will not work in a
clustered/sharded situation. It's why our transactions are scoped to a
single document, for example.

I will also note that all_or_nothing does not provide multi-document
ACID transactions. The batches used in bulk_docs are not recorded, so
those items will be replicated individually (and in parallel, so not
even in a predictable order), which would break the C and I
characteristics on the receiving server. The old semantic would abort
the whole update if any one of the documents couldn't be updated but
the new semantic simply introduces a conflict in that case.

B.

On 22 December 2011 16:48, Alexander Uvarov <[email protected]> wrote:
> And can become much easier with multi-document transactions as an option.
>
> On Thu, Dec 22, 2011 at 10:43 PM, Pepijn de Vos <[email protected]> wrote:
>> But not everyone needs a cluster. I like CouchDB because it's easy, not 
>> because "it scales", and in some situations, all_or_nothing is easy.
>>

Reply via email to