On Jul 8, 2013, at 12:17 AM, Jason Smith <[email protected]> wrote:
> The database has a purge_seq value which tracks the number of purges. I do > not recall if that is factored into the replication ID. It should be. For compatibility reasons [with TouchDB / Couchbase Lite] I’d love to know more about this. Is there any description other than the source code? > To me, purging is as if a document had never existed. A replication should > recreate it (unless you change your filter policy or validate_doc_update). Yup. I’ve heard from several people writing mobile apps who need something like this. Their mobile database doesn’t have room for everything on the central server, so they want to replicate subsets of it, and then if the client-side filter changes they need to be able to nuke the documents that aren’t in the new subset so the user’s phone doesn’t pop. If the purged docs could never be pulled again, this would break down when the user changed the filter such that a once-valid document was now valid again. (A reminder to everyone that the CouchDB architecture and replication protocol aren’t only used on big-iron servers. They also need to work on phones and netbooks and Raspberry Pi’s whose available storage may be ‘only’ a few hundred megs :) > CouchDB purge is like Git rebase: sure it is dangerous, but that's because > it is powerful; and sometimes power users need power tools. +1 :) —Jens
