incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad George <c...@mgproducts.com>
Subject Re: View design strategy, what to emit?
Date Tue, 28 Dec 2010 02:24:46 GMT
I believe its redundant to store the docid as the value (or key) of a view
row. When the view row is emitted by the map() function the docid is
attached to the key (for internal use). The View API has access to this and
provides the id, key, value for each row on retrieval.

Personally, I've been storing null as the value in the view and using
include_docs to get access to the document.

Unless you can't limit the view results sufficiently with startkey/endkey
... I don't see any reason to have a second call to retrieve the documents.



On Thu, Dec 23, 2010 at 9:15 AM, Simon Metson <simonmetson@googlemail.com>wrote:

> Hi,
>
>
>  Let's say the view searches across documents for a keyword. It's okay
>> to emit the entire doc or merely the docid as map result. I'm working
>> with couchdb-python here, and it appears complicated to convert
>> ViewResults to Documents which I'm comfortable to work with. So I
>> choose to emit only the docid, and run another loop to retrieve the
>> actual document.
>>
>> I'm wondering if this is a good approach. It'll require more API
>> calls, will it be slower?
>>
>
> It'll probably depend on the view, size of document etc. but I wouldn't be
> afraid of making 2 calls to CouchDB (it's designed for concurrency). You can
> also query the view with ?include_docs=true - that'll be more efficient in
> terms of space but slower than emitting the doc in the view.
>
> There's no hard and fast rule, though, and what works well in one use case
> may be dreadful in another. You might have very large docs that the client
> only needs a small part of, so why send it all?
>
>
>  And I wonder if emitting only docid is more space-efficiently (in
>> terms of view-occupied storage) than emitting the whole doc?
>>
>
> Yes, it is.
> Cheers
> Simon
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message