Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of awolff@gmail.com designates
 74.125.92.25 as permitted sender)
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
         :content-type;
        b=hJbzRGgrzHXJdZ1cxwCmi35skinRN6WS5NlOAM/76zL2dDaHFnOQ/GMlEcWkTvE0KZ
         xlQ2zh7V/mNhqb/8E/DvxKaYnTU0dozSXwpq94MFJbWGFOaC9E6/4iy4cVAz1CtThgyS
         CDJJQL99OgwhfeB41EGz5Gn3ydUQvrlnu30Q0=
MIME-Version: 1.0
In-Reply-To: <f728979f0906090847o671e806en44254c1aa58f1813@mail.gmail.com>
References: <e8d26ac40906090833h257bf9f6h5f11847057d7a60c@mail.gmail.com>
	 <f728979f0906090847o671e806en44254c1aa58f1813@mail.gmail.com>
Date: Wed, 10 Jun 2009 13:31:57 -0700
Message-ID: <e8d26ac40906101331l19af5defs99c6037556a412fc@mail.gmail.com>
Subject: Re: document revisions
From: Adam Wolff <awolff@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=0016364ef1ccdfd9ec046c045db0

--0016364ef1ccdfd9ec046c045db0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

*bump* I guess I'm talking about #4 on the page referenced below -- storing
off old document revisions. does that really make sense, or should I
consider a couchdb extension to just preserve document revisions?
A

On Tue, Jun 9, 2009 at 8:47 AM, Zachary Zolton <zachary.zolton@gmail.com>wrote:

> 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 <awolff@gmail.com> 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
> >
>

--0016364ef1ccdfd9ec046c045db0--