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"
