couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: couchdb (_external consistency issues and proposals)
Date Mon, 22 Dec 2008 06:44:13 GMT

On 21/12/2008, at 2:40 PM, Antony Blakey wrote:

> Also, if your _external doesn't get triggered for a long time, and  
> while it's 'dormant' a document is deleted and the db is compacted,  
> you could miss deletions. One solution to that is that every  
> _external needs to be notified (synchronously) before a compaction  
> so that it can update to the update_seq of the MVCC snapshot that  
> the compaction will operate against. IMO a better solution is to  
> have two UUID's for the database - one is per database, and one is  
> 'per compaction'. Thus an external will know if it needs to  
> revalidate all the documents it has indexed to check for missed  
> deletions updates. You could just have a per-compaction UUID, which  
> would change if a db was deleted and then created, this triggering  
> the same codepath, but this is a lot more expensive than knowing  
> that the entire db

I now know that this is wrong, sorry. Document deletions are never  
'lost', and hence there's no need to track compaction generations.  
That raises a very different issue I noted in 'History of deletion,  
and the interaction with compactions' on couchdb-dev, but it's nothing  
to do with _external.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Reflecting on W.H. Auden's contemplation of 'necessary murders' in the  
Spanish Civil War, George Orwell wrote that such amorality was only  
really possible, 'if you are the kind of person who is always  
somewhere else when the trigger is pulled'.
   -- John Birmingham, "Appeasing Jakarta"

View raw message