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 >
