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 >
