Compaction does not affect the changes feed.
On 23 August 2013 09:01, Jens Rantil <jens.ran...@gmail.com> wrote: > 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.ran...@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 >>
