Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CDB779938 for ; Mon, 5 Mar 2012 11:34:22 +0000 (UTC) Received: (qmail 84326 invoked by uid 500); 5 Mar 2012 11:34:21 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 84214 invoked by uid 500); 5 Mar 2012 11:34:21 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 84204 invoked by uid 99); 5 Mar 2012 11:34:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Mar 2012 11:34:21 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Mar 2012 11:34:14 +0000 Received: from [172.20.10.3] (unknown [2.212.133.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id 6BCB23C137 for ; Mon, 5 Mar 2012 12:33:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: Documentation issue From: Jan Lehnardt In-Reply-To: <20120303145454.191390@gmx.com> Date: Mon, 5 Mar 2012 10:41:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120303145454.191390@gmx.com> To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1257) X-Virus-Checked: Checked by ClamAV on apache.org On Mar 3, 2012, at 15:54 , Mike Coolin wrote: > So don't improve the documentation such as it is, read the tests? >=20 > I think Andrey has a point. Tests are not documentation, they are = guardrails and samples. My point was not that we shouldn't document this. Of course we should = document this, thanks for raising the issue. I took issue with these two sentences: "Problem with _purge that it was = not documented. That means this was not well tested." in particular that = there is somehow a causal relationship between non-documented features = and their well-testedness. While it is correct that well documented = features do get more real-world exposure, and thus testing, I just = wanted to point out that we do have tests for _purge that have been = around for a long time and that I am reasonably confident that it is a = stable feature. Sorry for the confusion! :) Cheers Jan --=20 > Cheers Mike >=20 > ----- Original Message ----- > From: Jan Lehnardt > Sent: 03/03/12 09:31 AM > To: user@couchdb.apache.org > Subject: Re: Documentation issue >=20 > On Mar 3, 2012, at 06:57 , Andrey N wrote: > Problem with _purge that = it was not documented. That means this was not well tested. I'd contest = that notion, there's been automatic tests for _purge ever since the = feature landed. Cheers Jan -- > > Thanks. >> To me it seems exactly the = same, but I'm not an expert. >> >> On Fri, Mar 2, 2012 at 3:39 PM, = Robert Newson wrote: >> >>> I said 'better' not = 'good'. :) >>> >>> On 2 March 2012 20:20, Mark Hahn = wrote: >>>>> A better solution is to periodically switch to a new = database and then >>>> delete the old one (when those sessions are = ended). >>>> >>>> How is that any different than purging? It also kills = replication. >