On Fri, Oct 10, 2008 at 9:52 AM, Paul Carey <[EMAIL PROTECTED]> wrote:
> I just came across the following issue when paging.
>
> Consider a database containing ten documents, each with a letter and
> number, as follows:
>
> a1, a2, a3, b1, b2, b3, b4, b5, c1, c2
>
> Offset (desc false) 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
>
> Imagine a user wants to retrieve all 'b' docs, displaying 2 docs per page
> We query with
>
>
> _view/Letter/all_sorted_by_letter_and_number?startkey=["b"]&endkey=["b",{}]&count=2&descending=false
>
> and receive b1, b2 with a offset of 3. The user hits next. We issue
> the query based on the data the user is currently viewing
>
>
> _view/Letter/all_sorted_by_letter_and_number?startkey=["b",2]&endkey=["b",{}]&count=2&descending=false&skip=1
>
> This returns b3, b4 with an offset of 5.
>
> The difficulty is with knowing whether to display a next / prev link.
> Assume we've written our reduce function so we know that 5 'b' docs
> exist. The total doc count, offset and number of docs returned isn't
> enough. We also need the original offset (3 in this case). Assuming we
> have that we can display a next link based on
> (offset - original_offset) + count < total_docs
>
> This approach then requires three queries per paginated page - one
> each for the data, original offset and total doc count (for the key) -
> and seems a little convoluted to me. Am I missing an easier approach?
>
> Thanks
I believe I remember seeing a thread about paging where Damien recommended
doing count+1 for the count -- meaning, get one more record then necessary.
You don't have to display the extra record, but it gives you all the data
you need to determine if you need a next link for additional records.
