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 <[email protected]> wrote: > > On Mar 31, 2013, at 21:48 , Dirkjan Ochtman <[email protected]> wrote: > >> On Sun, Mar 31, 2013 at 9:42 PM, Jan Lehnardt <[email protected]> wrote: >>> We will be collecting things here: >>> >>> https://issues.apache.org/jira/browse/COUCHDB-1756 >>> >>> There is an (incomplete) list of differences down on: >>> >>> http://bigcouch.cloudant.com/api >>> >>> Robert & Paul et.al 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 > -- >
