couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Is startkey_docid as scalable as startkey?
Date Thu, 05 Dec 2013 23:23:37 GMT
To be clearer, startkey_docid is *ignored* unless you also specify startkey.


On 5 December 2013 23:23, Robert Newson <> wrote:
> The question is meaningless, let me explain.
> startkey_docid (and endkey_docid) are used for selecting ranges where
> the view key is the same, it is *not* a separate index. Views are in
> key order only.
> under the covers, the true view key is actually [emitted_key_order,
> doc._id], the rows are unique in the b+tree.
> B.
> On 5 December 2013 23:14, Nathan Vander Wilt <> wrote:
>> Let's say for every doc I `emit([doc.user])` and, when a user requests a document
ID I have my middleware `GET …/docs_by_user?startkey=[]&endkey=[,{}]&include_docs=true&limit=1&`.
I return the row's doc or 404 if the range is empty. Basically I'm giving each user read access
to "their own" objects without having to give them their own database.
>> I'm wondering though, if `startkey_docid` is as scalable as `startkey` itself. IIRC,
the doc ids are simply a final extra group level internally (clearly they determine sort order)
but if this behaves more like `&skip=lots` instead, then of course relying heavily on
the query above would be something of an anti-pattern.
>> (Bonuses: If this _is_ still a reasonable solution, I'm assuming I can't simplify
my emit/query to use `&key=name&startkey_docid=id` right? Alternatively, would it
be more efficient but just-as-correct to emit plain string keys and limit my range to `&startkey=name&endkey=name+"\0"?)
>> thanks,
>> -natevw

View raw message