couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Changes API - purged?
Date Thu, 22 Aug 2013 09:58:16 GMT
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.


On 22 August 2013 10:26, Jens Rantil <> 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

View raw message