just building a log-of-changes may or may not be enough, depends on your what docs represent.
there is some "revisioning" here: http://blog.couchbase.com/simple-document-versioning-couchdb basically keeping all revisions as attachments. have fun ciao svil On Tue, 25 Sep 2012 14:02:09 -0500 Paul Davis <[email protected]> wrote: > 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
