couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@hahnca.com>
Subject Re: following fast doc updates
Date Wed, 26 Sep 2012 17:12:26 GMT
> 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 <rnewson@apache.org> 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 <bchesneau@gmail.com> wrote:
> > On Sep 25, 2012 8:32 PM, "Mark Hahn" <mark@hahnca.com> 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 <kocolosk@apache.org
> >>wrote:
> >>
> >> > On Sep 24, 2012, at 5:16 PM, Mark Hahn <mark@hahnca.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message