On Mon, Jul 8, 2013 at 11:47 PM, Jens Alfke <[email protected]> wrote:
> > 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 my knowledge, the best non-source resource is the email linked in the GitHub page I referenced in CQS. This is the sort of thing I used to ask Damien about around the office. Filipe also might know about purging too. Incidentally, there is no way the purge_seq would affect the replication ID since the latter is calculated before contacting the remote database. > > 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. > To me, if it is relevant whether a document "exists" or not compared to a central server, and respecting some changing replication policy, then purging is not appropriate, _deleting is. I understand the storage contraints, but the *fact* that a document is here or not, is itself information worth storing. (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 :) > Hear, hear! Scaling "down" is an interesting and important requirement, and less fraught with the ethical problems that Big Data tends to bring.
