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

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        81d 15h 57m 1 Jan Lehnardt 09/Sep/08 11:25
        Jan Lehnardt made changes -
        Field Original Value New Value
        Resolution Won't Fix [ 2 ]
        Status Open [ 1 ] Closed [ 6 ]
        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.
        antirobotrobot created issue -

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development