Brian writes:
On Fri, Feb 19, 2010 at 02:29:50PM +1100, Mark Hammond wrote:
I guess is might be possible for a document to be deleted between
the view row being processed and the doc being opened for the view
result but I don't think this is happening here - the view also
emits the document _rev
I didn't think the view Btree index included the _rev. If it did it would
allow really neat things like proper view etags, as well as preventing the
race condition you describe.
However if it did, I would also expect the rev to be in the raw view rows,
i.e.
{"id":"xxx","rev":"yyy","key":"aaa","value":"bbb","doc":{...}}
^^^^^^^^^^^
Do you mean that you have emit(..., {_rev: doc._rev}) in your view?
Correct.
I tracked the code returning null to couch_httpd_view:doc_member - it does:
case (catch couch_httpd_db:couch_doc_open(Db, DocId, Rev, [])) of
There is a LOG_DEBUG just above that. What does it show? In particular, is
Rev nil? In that case you'll just get "current" version. Or is it getting
the rev of a deleted doc?
I came to the conclusion couch had a null rev, so is attempting to get
the latest. I haven't seen this happen with debug logs - it happens
fairly rarely. I did add another log for that error case and saw couch
is reporting the error as not_found.
Adam writes:
Mark, is it fully reproducible? You can always read the document directly, but
never through include_docs=true?
It isn't "fully" reproducible as such, but a test suite I have will
strike this on one particular test rougly 5-10% of the times it is run.
I'll try logging what _rev couch is attempting to use...
Cheers,
Mark
