On 21/12/2008, at 6:05 PM, Chris Anderson wrote:
I think you are right on about no
synchronous guarantees between updates, and code in external being
run. Marking as dirty is a good way to handle this.
Without some timing guarantee I think even setting dirty is
problematic, because it's possible to set a dirty flag from a
notification, and yet have a request from the external (e.g. all docs
by seq) see a both the dirty flag and pre-notification state, and
hence cache old data thinking it's post-notification.
It's the avoidance of this kind of synchonisation problem that makes
me think a UUID for the db and a UUID for the generation wrt
compaction is a good idea. It reifies state boundaries in a way that
can be used by external tools. I don't think there's any other way
around it.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Human beings, who are almost unique in having the ability to learn
from the experience of others, are also remarkable for their apparent
disinclination to do so.
-- Douglas Adams