Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 87257 invoked from network); 9 Jun 2009 15:47:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Jun 2009 15:47:46 -0000 Received: (qmail 10918 invoked by uid 500); 9 Jun 2009 15:47:57 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 10835 invoked by uid 500); 9 Jun 2009 15:47:57 -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 10825 invoked by uid 99); 9 Jun 2009 15:47:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Jun 2009 15:47:57 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of zachary.zolton@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; Tue, 09 Jun 2009 15:47:47 +0000 Received: by bwz18 with SMTP id 18so96595bwz.11 for ; Tue, 09 Jun 2009 08:47:27 -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 :from:date:message-id:subject:to:content-type; bh=eDZS0dvhUoRo3M+pN8budhZ1p9HNM3larETxvhC/K0Y=; b=UXeYjSCauVlTQrYafcK7geE5ppINH6VjXffYVlxoGjkVohdE4GLm3AWy/WdUw9qx6g XrIIiFvYnjOXURm85YJCqQqxWmJ4pVanHqja4zC82FsV9H/qZ8XY57pirIfpQRy1fIFK EimUj0I5EcpiZnTCovulJGO7MK8oQB7e32xt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=LvzkNWvR4Jf+M8XvRUoE9m5Vc953ydThA/ckLF4v+rMW+y5rE6GDgwwvC6ooyE71N+ KPEhvfpDHX6G2nq+IwiKUfhpWH43tkHvGu1qmUgEx91czXHGZLw4JoQvg4K7LOyZ/Wvw Ys7El2RNwOOpQwookqbS2JLpn9mv5JT3UXPVY= MIME-Version: 1.0 Received: by 10.216.10.74 with SMTP id 52mr90155weu.226.1244562446263; Tue, 09 Jun 2009 08:47:26 -0700 (PDT) In-Reply-To: References: From: Zachary Zolton Date: Tue, 9 Jun 2009 10:47:06 -0500 Message-ID: Subject: Re: document revisions To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=001485f6cd0682a58d046bec465d X-Virus-Checked: Checked by ClamAV on apache.org --001485f6cd0682a58d046bec465d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You'll want to model your documents in terms of revisions. For some ideas, see approaches 3 and 4 on this wiki page: http://wiki.apache.org/couchdb/How_to_design_for_replication On Tue, Jun 9, 2009 at 10:33 AM, Adam Wolff wrote: > Hi everyone,Our app needs to preserve document revisions. I know that the > revision feature of couchdb is not intended for application-level document > revisions, but the semantics of couch's revisions are perfect for our app, > and I don't want to have to rebuild that feature. What's the best way to > take advantage of couch's built-in revisions? I know we can't rely on the > revisions being there, but they *are* there right after you write a new > version. After a successful write, the caller could be responsible for > putting a separate document for the old revision, right? > > Alternatively, is this a mod to couchdb that we should explore? A feature > so > that you can say: for the documents in this database, preserve the > revisions > even upon compaction. > > Thoughts? Thanks, > A > --001485f6cd0682a58d046bec465d--