How to I grant mega points for a fantastic answer? Thanks Jason.
A summary from the link....I have a master couchapp that clients pull replicate from. A refactoring of the couchapp may mess up the rev number for the main design doc. So i need a way to go past the rev number to force an update to the clients. Is there a better way? On Aug 21, 2011 9:40 PM, "Jason Smith" <[email protected]> wrote: > On Mon, Aug 22, 2011 at 8:43 AM, Ryan Ramage <[email protected]> wrote: >> I have a need to make a document revision number go up a lot. eg from >> 245-xxxx... to 430-xxxxx.... >> >> My reason for is here: >> http://groups.google.com/group/couchapp/browse_thread/thread/c51903ad5096fe2 >> >> >> What is the fastest/best way of doing this? > > ## Preamble > > CouchDB is a lot like Git. > > In Git, you have huge freedom to rewrite the commit history. If you > have special needs, you can make radical changes to commits and > branches (which are commit histories, all aggregated together). > > In CouchDB, you have huge freedom to rewrite the revision history. If > you have special needs, you can make radical changes to revision > histories and documents (which are revision histories, all aggregated > together). > > In other words, create a conflict (in Git these are called "branches") > and demote (delete) the unwanted document revision. > > In other words, suppose your doc _rev is "245-abcdef". > > POST /db/_bulk_docs > Content-Type: application/json > > { "all_or_nothing": true > , "docs": [ {"_id", "some_doc", "this_works":true, "_rev":"430-fedcba"} ] > } > > Response: [{"id":"some_doc", "rev":"431-ab4935e188dc777d59b5fcfc2d942f29"}] > > **Note** the revision is not what you requested, but rather the > subsequent revision, which makes sense. > > DELETE /db/some_doc?rev=245-abcdef > > Response: {"ok":true, "id":"some_doc", > "rev":"2-eec205a9d413992850a6e32678485900"} > > P.S. Sorry, I did not read your link explaining *why* you need this. I > am only addressing how to do it. IMO, tracking deployment versions, > build numbers, etc. is application-level data and therefore should not > depend in _rev. I see the temptation, though. _rev looks a lot like a > vector clock plus checksum of the document contents. > > -- > Iris Couch
