> A common approach is to save the current document as an attachment when you make an update
I am essentially doing this in my new scheme. But actually I only store a named flag that tells what portion of the doc changed along with a version stamp. I don't need to know the old values. But I have to keep a record in ram of the latest version of every doc, otherwise I have no idea what changes have already been processed. I could of course remove the flag when the change is processed, which would remove the need for the ram table, but that would cause the double writing of every doc. A lot of schemes I considered caused double writing. Saving a separate doc for each change would also double the number of writes. On Wed, Sep 26, 2012 at 3:01 AM, Robert Newson <[email protected]> wrote: > "then look at the history to see whether there are any intermediate > revisions after the last one you knew about. If there are, you can > fetch those too." > > Unless you compacted in between, in which case that data won't be there. > > The fundamental mistake being made here is believing that CouchDB even > attempts to preserve a full history of your changes. It doesn't, and > you will encounter problems if you think it does. And, to be > absolutely clear, Jens' idea will not work unless you are prepared to > be very careful about compaction scheduling (which I consider one of > the largest CouchDB anti-patterns). An application should not break if > someone compacts at the "wrong" time. > > CouchDB preserves only the current version of your data. Therefore, > ensure the current version of your data includes *all* your data. In > your case, your data is not just the current revision of documents, > but also the history of changes. Make that a first class part of your > application. Benoit's suggestion seems easiest, save the change as a > document itself (Use a view to collate all the changes). You can also > do it within the document too. A common approach is to save the > current document as an attachment when you make an update > (jquery.couch.js can already do this, > https://friendpaste.com/inEzmxy0R933i0N4kyicj). > > B. > > On 26 September 2012 07:46, 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 >
