couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: The BigCouch merge, CouchDB 2.0, 3.0 and later
Date Sun, 31 Mar 2013 20:24:43 GMT
It's not going away. It still exists on the back end interface, but it's the admins job to
purge at all replicas. The AP clustering model cannot guarantee a cluster-wide purge. 

The reason BigCouch doesn't support purge is that we need to synchronise replicas of the same
shard. Purging removes all trace of a document, so it can easily cause replicas to be different
forever. This is bad for a database. :)

Sent from my iPhone

On 31 Mar 2013, at 20:55, Jan Lehnardt <> wrote:

> On Mar 31, 2013, at 21:48 , Dirkjan Ochtman <> wrote:
>> On Sun, Mar 31, 2013 at 9:42 PM, Jan Lehnardt <> wrote:
>>> We will be collecting things here:
>>> There is an (incomplete) list of differences down on:
>>> Robert & Paul will help getting the COUCHDB-1765 filled out for
>>> discussion & details.
>> Thanks, that looks very useful (and takes away pretty much all of my
>> qualms). Will _purge be going away entirely?
> I’d like to keep it, but the current version isn’t cluster-able (Robert
> says), so we’d need a new way of implementing this.
> When we discussed this we differentiated two different points in time:
>  1. When is BigCouch ready to merge into Apache CouchDB?
>  2. When do we ship it?
> I’d say 1. can live without _purge as long as we get it back for 2. or 
> we decide as a group that we don’t want it anymore, and we can discuss
> that as part of COUCHDB-1765 or sub-issues.
> There are a few more features like this (vhosts e.g.) that need to go
> through a similar phase. We mainly made the distinction of requirements
> so make sure we get the BigCouch merge work in as soon as possible, so
> the current work gets stale again.
> Jan
> --

View raw message