couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hammond <>
Subject Re: include_docs returning doc=null
Date Fri, 19 Feb 2010 23:59:24 GMT
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?


>> 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...



View raw message