To be clearer, startkey_docid is *ignored* unless you also specify startkey.
B. On 5 December 2013 23:23, Robert Newson <rnew...@apache.org> 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 <nate-li...@calftrail.com> 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=[req.user.name]&endkey=[req.user.name,{}]&include_docs=true&limit=1&startkey_docid=req.param.id`. >> 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