incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Hallett <halle...@gmail.com>
Subject Re: couchdb: suitable for this type of applications ?
Date Sun, 27 Sep 2009 01:24:06 GMT
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 version 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 of previous version.
>>
>> Is this how I should model it in CouchDB:
>>  - have a version field, not using the CouchDB _rev. update the version in my application.
>>  - when uploading the modified Word document, a doc with a different ID is created.
So compacting a DB will not affect them.
>>    but how to get a list of all versions of this document ? I need to use another
field to identify them, for example, another application generated ID.
>>
>> Is this the general practice ? I am sure supporting versioning is a common 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 acts as a
> gatekeeper for writes to a document in CouchDB’s MVCC system. A document is a shared
> resource, many clients can read and write them at the same time. To make sure two
> writing clients don’t step on each others feet, each client must provide 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’t,
the
> update will be rejected. The client should read the latest version, integrate 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, the 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 that the document
> has changed. If you want to alleviate such concerns you should emit an object with a
_rev
> attribute as in emit(key, {"_rev": doc._rev}). This alleviates the race condition 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
>

Mime
View raw message