I'd be +1 returning an error. In fact we used to IIRC. Paul
On Thu, Feb 18, 2010 at 10:29 PM, Mark Hammond <[email protected]> wrote: > I've struck a rare case where a view request with include_docs=true (but no > stale=ok and no custom _id emitted from the view) is returning a row with > doc=null. > > 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, and > directly after getting doc=null I can open the specified document in futon > and it has the same _rev as the view row. Unfortunately, couch is not > offering any clues about what the problem is. > > 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 > #doc{} = Doc -> > JsonDoc = couch_doc:to_json_obj(Doc, []), > [{doc, JsonDoc}]; > _Else -> > [{doc, null}] > > So should the doc fail to open for any reason, you just get a null and the > reason for the failure is discarded. Is this by intent? ISTM it would be > better to instead, or also, provide an {error, Reason} element in the view > row. > > Does this sound desirable? If so, should an error still leave a doc=null > element, or only include the error element? Let me know and I'll open a but > and submit a patch... > > Cheers, > > Mark >
