>> I have been working on a scheme that relies on tracking every change.
>To do what? I have a sort of pub-sub. The client (through a wbsocket) can ask to be notified on changes. The subscription can be for just part of a doc. For example a product doc may be followed to watch for just price changes. The same doc may be followed by a different subscription to watch for product spec changes. (made up example). Before now I've just been publishing the record to everyone on any doc change. This causes a lot of unnecessary traffic and what's worse is that client code does a lot of work updating the DOM and other things way more often than necessary, causing ugly things to happen. > Why not storing a change as a new doc? This would change the _id which would break whatever linking there is between records. On Tue, Sep 25, 2012 at 11:46 PM, Benoit Chesneau <[email protected]>wrote: > On Sep 25, 2012 8:32 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. > To do what? > > 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. > > Why not storing a change as a new doc? > > > > 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 >
