Excellent, thanks! Third times a charm, or…should answer your followup question anyway ;-) -nvw
On Dec 5, 2013, at 3:29 PM, Robert Newson <[email protected]> wrote: > Well, that'll teach me to multi-task and skim emails... > > startkey_docid is the same 'scalability' as startkey, in the sense > that startkey and startkey+startkey_docid are O(log n) lookups. > > key=name&startkey_docid=id ought to work as key=foo is, internally, > startkey=foo&endkey=foo (possibly verbatim). > > To get back to your use case, I'm assuming doc.user is not unique but, > somehow, you know the doc id of the user you're looking for? If so, > why not just use _all_docs?key=req.param.id and don't build the view > at all? > > > > > On 5 December 2013 23:23, Robert Newson <[email protected]> wrote: >> To be clearer, startkey_docid is *ignored* unless you also specify startkey. >> >> B. >> >> >> On 5 December 2013 23:23, Robert Newson <[email protected]> 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 <[email protected]> >>> 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
