couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <nate-li...@calftrail.com>
Subject Re: Is startkey_docid as scalable as startkey?
Date Thu, 05 Dec 2013 23:33:50 GMT
Excellent, thanks! Third times a charm, or…should answer your followup question anyway ;-)
-nvw


On Dec 5, 2013, at 3:29 PM, Robert Newson <rnewson@apache.org> 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 <rnewson@apache.org> wrote:
>> To be clearer, startkey_docid is *ignored* unless you also specify startkey.
>> 
>> B.
>> 
>> 
>> On 5 December 2013 23:23, Robert Newson <rnewson@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-lists@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


Mime
View raw message