Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of hallettj@gmail.com designates
 209.85.210.176 as permitted sender)
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:content-transfer-encoding;
        b=B1RacdUp8Slhch6oAi0L05xnMZ8QVsEd1PLXnP3fnD8o8zlkzG3HkXpL3to26pSBOS
         Ri0NBHdL5MZKgTO3iJbU+Wr7GB+THZdJDg7Z6TosQpf2TCPhGNztTnh5P92qMcY1SELu
         p4O8FabUqovwE4FH+SIKl/1Q0bIzS4kHPdtvQ=
MIME-Version: 1.0
In-Reply-To: <e282921e0909260022t732d7f0bhed8d1744b0617bb1@mail.gmail.com>
References: <796695.24188.qm@web45314.mail.sp1.yahoo.com>
 <8a02878f0909251832n3358d3b3s4d0dfe4513917500@mail.gmail.com>
	<8a02878f0909251839g655b83aak3bd01ee753dc2cac@mail.gmail.com>
	<882214.95805.qm@web45315.mail.sp1.yahoo.com>
 <e282921e0909260022t732d7f0bhed8d1744b0617bb1@mail.gmail.com>
From: Jesse Hallett <hallettj@gmail.com>
Date: Sat, 26 Sep 2009 18:24:06 -0700
Message-ID: <8a02878f0909261824i83e649w4cda46739a852860@mail.gmail.com>
Subject: Re: couchdb: suitable for this type of applications ?
To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 26, 2009 at 12:22 AM, Chris Anderson <jchris@apache.org> wrote:
> On Fri, Sep 25, 2009 at 8:34 PM, go canal <gocanal@yahoo.com> wrote:
>>>>When you compact the database it removes all but the most recent versio=
n of each document.
>>
>>
>> Does this mean that if I want to support document version feature, I can=
 not compact the database ?
>>
>
> Applications should not depend on controlling compaction schedules.
> Only the most recent version is replicated, so if you run in a cluster
> it's like it's compacting all the time.
>
>> Let's say I am working on a Word document, I upload it as an attachment;=
 I need to have a list of all versions for this file and can download any o=
f previous version.
>>
>> Is this how I should model it in CouchDB:
>> =A0- have a version field, not using the CouchDB _rev. update the versio=
n in my application.
>> =A0- when uploading the modified Word document, a doc with a different I=
D is created. So compacting a DB will not affect them.
>> =A0 =A0but how to get a list of all versions of this document ? I need t=
o use another field to identify them, for example, another application gene=
rated ID.
>>
>> Is this the general practice ? I am sure supporting versioning is a comm=
on request, so appreciate if you can provide some advices..
>> thanks,
>> canal

That approach seems reasonable.  In any case content versioning is an
application level concern.  CouchDB's multiple revision feature is
used to detect update conflicts and to prevent race conditions.

>From CouchDB: The Definitive Guide
<http://books.couchdb.org/relax/example-app/storing-documents>:

> We touched on this in the Eventual Consistency chapter. The revision id a=
cts as a
> gatekeeper for writes to a document in CouchDB=92s MVCC system. A documen=
t is a shared
> resource, many clients can read and write them at the same time. To make =
sure two
> writing clients don=92t step on each others feet, each client must provid=
e what it believes is
> the latest revision id of a document along with the proposed changes. If =
the on-disk
> revision id matches the provided _rev, CouchDB will accept the change. If=
 it doesn=92t, the
> update will be rejected. The client should read the latest version, integ=
rate his changes and
> try saving again.

>From the CouchDB Wiki <http://wiki.apache.org/couchdb/HTTP_view_API>:

> The include_docs option will include the associated document. Although, t=
he user should
> keep in mind that there is a race condition when using this option. It is=
 possible that
> between reading the view data and fetching the corresponding document tha=
t the document
> has changed. If you want to alleviate such concerns you should emit an ob=
ject with a _rev
> attribute as in emit(key, {"_rev": doc._rev}). This alleviates the race c=
ondition but leaves
> the possiblity that the returned document has been deleted (in which case=
, it includes the
> "_deleted": true attribute).

> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>