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 <[email protected]> To: [email protected] 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 <[email protected]> wrote: > On Fri, Sep 25, 2009 at 8:34 PM, go canal <[email protected]> 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 >
