Ah, I had not considered multiple emits per doc.
Thanks very much!
Jason Gordon | Principal | A S S U R E B R I D G E
Office: +1 888 409 6995 | Mobile: +1 978 885 6102 | Fax: +1 888 409
6995
Email: jason.gor...@assurebridge.com
On Fri, Apr 7, 2017 at 3:33 PM, Jan Lehnardt wrote:
>
> > O
> On 7 Apr 2017, at 19:15, Jason Gordon wrote:
>
> Hi Jan,
>
> You raise a good point. But it leads to another, similar question
>
> If rows 50 and 51 both contain a user with lastname Jackson, the recipe
> says to use the following as the next key
>
> startkey=[02134,Jackson] endKey=[02134,
No, the “startkey_doc_id” is only considered after the start key is applied.
For example:
key=[02134], id=123
key=[02134], id=567 <- your second query starts from here
…
key=[02134, Jackson], id=234 <- not here
Make sense? In other words, the view is actually indexed under the hood by the
[key,
Hi Jan,
You raise a good point. But it leads to another, similar question
If rows 50 and 51 both contain a user with lastname Jackson, the recipe
says to use the following as the next key
startkey=[02134,Jackson] endKey=[02134,{}] limit=51 startkey_doc_id=234
(assuming _id for Jackson 234)
bu
> On 6 Apr 2017, at 21:18, Jason Gordon wrote:
>
> The CouchDB docs 6.2.5 pagination recipe recommends to use the
> "startkey_docid for pagination if, and only if, the extra row you fetch to
> find the next page has the same key as the current startkey"
>
> Why can't you keep the start key the
The CouchDB docs 6.2.5 pagination recipe recommends to use the
"startkey_docid for pagination if, and only if, the extra row you fetch to
find the next page has the same key as the current startkey"
Why can't you keep the start key the same and just keep updating the
startkey_docid?
For example
