couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Rantil <jens.ran...@gmail.com>
Subject Re: Changes API - purged?
Date Fri, 23 Aug 2013 08:01:54 GMT
Robert,

Thanks you for your e-mail. This was great information!

Just to be clear, does compaction influence the changes feed in any way?

Thanks,
Jens

Den torsdagen den 22:e augusti 2013 skrev Robert Newson:

> If you use _purge then, yes, the information is purged, which is one
> of the many reasons you should not use _purge. :)
>
> The replicator uses changes for the same purpose as you intent, where
> the 'external state' is also a couchdb database in another server. You
> can rely on it to contain everything you need to synchronize an
> external stateful system with your database.
>
> For the avoidance of doubt, the changes feed does *not* preserve every
> change made to your database. It has one entry for every doc id that
> has ever been present in your database, in the order of their most
> recent update. Starting from an empty database, the first document
> added will have update sequence 1. If you update or delete that
> document, then the changes feed will have no entry for update sequence
> 1 but will have an entry for update sequence 2. If you apply every
> update in the order you receive it from _changes to your target
> system, you will end up in the correct state.
>
> B.
>
>
> On 22 August 2013 10:26, Jens Rantil <jens.rantil@gmail.com <javascript:;>>
> wrote:
> > Hi,
> >
> > I have a use case where I'd like to build up an external state by
> following
> > the changes of a database. Obviously, the /db/_changes will be a great
> > source to start for this. My question is, can I always be sure that
> simply
> > following /db/_changes from seqnum=0 will bring me to a consistent state
> of
> > the current database? Are /db/_changes purged (on /db/_purge?) in any way
> > throughout the lifetime of a database?
> >
> > I've tried finding this information in documentation, but have failed so
> > far.
> >
> > Thanks,
> > Jens
>

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