Alternatively, you could use two dbs. One db you could write "change requests" to (each request as a new doc) and then listen for changes on that and apply them in that logic. This also has that added benefit that you could do the timestamped dbname pattern for your changes feed dbs to (possibly depending on use case) remove some of the cruft buildup.
On Tue, Sep 25, 2012 at 1:31 PM, Mark Hahn <[email protected]> wrote: >> The _changes feed only ever shows leaf revisions > > AARRGGHH. I am so screwed. I have been working on a scheme that relies on > tracking every change. And as everyone knows there is normally no way to > find out what changed in a doc. I am going to have to add a history of > changes to each doc which it not only wasteful, but a pain to implement. > > Thanks for taking the trouble to give me bad news. > > > On Tue, Sep 25, 2012 at 10:19 AM, Adam Kocoloski <[email protected]>wrote: > >> On Sep 24, 2012, at 5:16 PM, Mark Hahn <[email protected]> wrote: >> >> > If I update a particular doc multiple times rapidly, is each update >> > guaranteed to show up in a continuous changes feed? I am worried that >> the >> > change feed will be optimized to just show the latest value of a doc with >> > multiple updates. This would break my logic. >> >> Your worries are justified. The _changes feed only ever shows leaf >> revisions (i.e., latest updates to branches of the edit tree). Regards, >> >> Adam
