incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: Emiting a Doc from Erlang View
Date Mon, 03 Oct 2011 18:01:55 GMT
On Mon, Oct 3, 2011 at 11:50 PM, Jens Alfke <jens@couchbase.com> wrote:
>
> On Oct 3, 2011, at 4:53 AM, Thomas Van de Velde wrote:
>
> I thought include_docs only works when you have a reduce function defined as well.
>
> Nope, it always works. But if you’re going to use it all the time, it’s faster to
just emit the document into the view, as that saves a b-tree lookup per row every time the
view is fetched.

include_docs does not always work. However, IMO Jens gives good
advice. For 99% of developers, 99% of the time, it works as expected.

include_docs just more syntactic sugar where CouchDB does the same
thing a client would do: no more, no less.

The well-known syntactic sugar is _update functions. They are not
magic, they are the same fetch/modify/store cycle we all know. Since
they are very low-latency, they rarely get 409 conflicts, but it does
happen!

include_docs is the same. There is a low-latency lookup by doc ID but
it is not magic either. If you emit {_id:"doc_id"} then CouchDB will
fetch the latest revision (like GET /db/doc_id). If you are very
unlucky, or if there is a high update frequency, you could get a
different revision from that which caused the view row.

If you emit {_id:"doc_id", _rev:"rev-token"} then it will fetch
exactly the revision specified (like GET /db/doc_id?rev=rev-token),
which might be missing if it was compacted away.

In both cases, the document might be deleted during the interim as
well. None of these concerns apply if you emit the doc directly into
the view row. Instead, you get more disk usage, so it is a trade-off.

-- 
Iris Couch

Mime
View raw message