CouchDB
  1. CouchDB
  2. COUCHDB-82

total_rows should be the number of rows returned if the count parameter is not supplied

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Database Core
    • Labels:
      None

      Description

      I need the ability to paginate though a subset of a view. I make view requests with startkey, endkey, and count. I would like to paginate through these rows, but I cannot know the total rows between startkey and endkey without making an extra view which adds up the totals.

      It would be much better if total_rows, returned in the view, reflected the number of rows that would be returned had the count parameter not been supplied.

        Activity

        Hide
        Jan Lehnardt added a comment -

        CouchDB streams view results directly from the index to the client, there is no way to know in advance how big a result set is and buffering everything to do a count is not a good idea. won't fix. a workaround is a reduce function to do the counting for you.

        Show
        Jan Lehnardt added a comment - CouchDB streams view results directly from the index to the client, there is no way to know in advance how big a result set is and buffering everything to do a count is not a good idea. won't fix. a workaround is a reduce function to do the counting for you.
        Hide
        antirobotrobot added a comment -

        Why this is necessary: without it the majority of pagination use cases will require two requests. One map request to get the rows, and a second map-reduce request to calculate the total rows.

        Imagine a livejournal-like application with blog posts owned by different users. We want a paginated view of a single user's posts. Certainly one view could be made which does
        emit( [doc.user_id, doc.post_date], doc );
        And we can query all of the posts of John using startkey=["john"] endkey=["john", []]. Happily CouchDB tries to solve pagination for us, so we attached count=10 to the view query to get the first 10 posts of john. However, the total_rows parameter returned by the request tells us how many posts there are in total, not how many John has. This can be solved with a second request. Or alternatively it could be solved by having a view for each user on livejournal.

        Show
        antirobotrobot added a comment - Why this is necessary: without it the majority of pagination use cases will require two requests. One map request to get the rows, and a second map-reduce request to calculate the total rows. Imagine a livejournal-like application with blog posts owned by different users. We want a paginated view of a single user's posts. Certainly one view could be made which does emit( [doc.user_id, doc.post_date] , doc ); And we can query all of the posts of John using startkey= ["john"] endkey=["john", []]. Happily CouchDB tries to solve pagination for us, so we attached count=10 to the view query to get the first 10 posts of john. However, the total_rows parameter returned by the request tells us how many posts there are in total, not how many John has. This can be solved with a second request. Or alternatively it could be solved by having a view for each user on livejournal.

          People

          • Assignee:
            Unassigned
            Reporter:
            antirobotrobot
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development