incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@apache.org>
Subject Re: Purging documents and view invalidation
Date Mon, 08 Jul 2013 17:13:40 GMT
On Mon, Jul 8, 2013 at 11:47 PM, Jens Alfke <jens@couchbase.com> wrote:

>
> On Jul 8, 2013, at 12:17 AM, Jason Smith <jason.h.smith@gmail.com> 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message