incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From go canal <goca...@yahoo.com>
Subject Re: couchdb: suitable for this type of applications ?
Date Sun, 27 Sep 2009 02:34:28 GMT
Thanks Jesse. I also learn a lot from your (?) post http://sitr.us/2009/06/30/database-queries-the-couchdb-way.html
 rgds,
canal




________________________________
From: Jesse Hallett <hallettj@gmail.com>
To: user@couchdb.apache.org
Sent: Sunday, September 27, 2009 9:24:06 AM
Subject: Re: couchdb: suitable for this type of applications ?

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message