From dev-return-7027-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Oct 29 05:48:03 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 34229 invoked from network); 29 Oct 2009 05:48:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Oct 2009 05:48:02 -0000 Received: (qmail 22659 invoked by uid 500); 29 Oct 2009 05:48:01 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 22568 invoked by uid 500); 29 Oct 2009 05:48:01 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 22496 invoked by uid 99); 29 Oct 2009 05:48:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Oct 2009 05:48:01 +0000 X-ASF-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com designates 209.85.218.218 as permitted sender) Received: from [209.85.218.218] (HELO mail-bw0-f218.google.com) (209.85.218.218) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Oct 2009 05:47:58 +0000 Received: by bwz10 with SMTP id 10so207871bwz.35 for ; Wed, 28 Oct 2009 22:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9CpzNyTgBAlmblyyjvCJQQRau8eHVwCAx4W+gLUUwuo=; b=jFe0HUFofklkchkmhc1fLqvfkjTQ81tcDtMxB/HgrJLtuHAGfoy7q+szrGBYFNvrFl x4TbAZJ1HzjdAQibovkOB1psaim0RAzJXAioDyLGDRT9tVJKuoogTgEeCi3suEU65wPj 9rG89VIE0G3XRpKLg0OEIoo/mY5jC414jmHtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DjMx4xuMkNLW3lBdyINwatG35WC+H8p/jwiwiu+gqm3WTrIL9cFveqHbyhEb5cvE+t S/wT4xXdAMiW9TrnQaSlCGq6Zp6ScTzP5o67rsMrrn50H6IpxU0Q0Xf9oPMAn/uL894/ MRmgQBDArIfcZXp2ZYLSeIawPn/t5BCgKexic= MIME-Version: 1.0 Received: by 10.204.10.6 with SMTP id n6mr4034870bkn.27.1256795257213; Wed, 28 Oct 2009 22:47:37 -0700 (PDT) In-Reply-To: References: <11513.194.29.98.144.1256639065.squirrel@themacaque.com> <8098243e0910270736p5d16229bs58324a446bc4f570@mail.gmail.com> Date: Wed, 28 Oct 2009 22:47:37 -0700 Message-ID: Subject: Re: Where do deleceted docs go From: Randall Leeds To: user@couchdb.apache.org, dev@couchdb.apache.org Cc: thomas@delaet.org Content-Type: multipart/alternative; boundary=000325558acedc933a04770c72bd --000325558acedc933a04770c72bd Content-Type: text/plain; charset=UTF-8 Aaaannnd... grepping the source gets me the answer in about 30 seconds. If my Erlang literacy serves me right, it looks like: POST /db/_purge with body: {'doc1': ['1-42793874', '2-2348759', ... ], 'doc2': ['8-12341', '10-850234']} Just tried it on my machine and it appears to work fine with 0.10.0. The only thing that bothers me is that requesting a document with ?revs=true returns a list of rev "ids" which are only the part of the rev after the dash (eg '28a4512efc7' instead of '3-28a4512efc7') but in order to purge a document you have to specify the full revision identifier with both parts. ?rev_info=true gives you access to this information, but why isn't it returned with ?revs=true? -Randall On Wed, Oct 28, 2009 at 22:28, Randall Leeds wrote: > I don't see any purge api documented anywhere? > Can someone explain how this works or where I can find info? > As always, I'd gladly update the wiki. > > -Randall > > > On Wed, Oct 28, 2009 at 05:42, Paul Davis wrote: > >> On Wed, Oct 28, 2009 at 8:39 AM, Paul Davis >> wrote: >> > On Wed, Oct 28, 2009 at 8:29 AM, Thomas Delaet >> wrote: >> >> If I understand this correctly, the fact that you can not rely on >> >> deleted documents being available cripples the synchronization >> >> mechanism. >> > >> > Compaction only removes the body of deleted documents. Revisions are >> > kept around specifically for this reason. >> > >> > HTH, >> > Paul Davis >> > >> >> Also, on a side note, for people wanting the "remove this document in >> such a matter that replication will *not* delete the document in the >> target db" you want to use the purge API. This is generally *not* what >> most people should use. Purge exists for things like rebalancing nodes >> in a cluster. Effectively operations that want to 'reparent' a docid >> to a different shard or some such. >> >> Paul Davis >> > > --000325558acedc933a04770c72bd--