Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#11072 closed enhancement (wontfix)

[cla][patch] Allow for pagination by adding totalRecords to data api

Reported by: Jonathan Bond-Caron Owned by: Jared Jurkiewicz
Priority: high Milestone: tbd
Component: Data Version: 1.5.0b1
Keywords: Cc:
Blocked By: Blocking:


The current data api doesn't allow for pagination.

This patch:

  • Adds recordsTotal to the fetch() request.
  • Example for ItemFileReadStore?.js
  • Shuffles around the documentation do that fetch() has signature:


You'll notice I commented out '', not sure the best way of doing it, but that documentation feels more appropriate in Request.js.

Attachments (1)

totalRecords.patch (17.9 KB) - added by Jonathan Bond-Caron 11 years ago.
Sample patch

Download all attachments as: .zip

Change History (6)

Changed 11 years ago by Jonathan Bond-Caron

Attachment: totalRecords.patch added

Sample patch

comment:1 Changed 11 years ago by Jared Jurkiewicz

Resolution: invalid
Status: newclosed

The data api does allow for pagination. The attribute name of request isn't 'totalRecords' it is 'count. See documentation:

See the keywordArgs option The *count* parameter.

If a count parameter is specified, this is a indication to the datastore to only return up to that many items. This allows a fetch call that may have millions of item matches to be paired down to something reasonable.

And there is the onBein parameter, it is intentionally the callback used to send back how large the resultset is:

See docs:

The *onBegin* parameter.

function(size, request); If an onBegin callback function is provided, the callback function will be called just once, before the first onItem callback is called. The onBegin callback function will be passed two arguments, the the total number of items identified and the Request object. If the total number is unknown, then size will be -1. Note that size is not necessarily the size of the collection of items returned from the query, as the request may have specified to return only a subset of the total set of items through the use of the start and count parameters.

comment:2 Changed 11 years ago by Jared Jurkiewicz

Milestone: 1.6tbd

comment:3 Changed 11 years ago by Jonathan Bond-Caron

Resolution: invalid
Status: closedreopened

What if a widget *needs* to know the *total number of records* for pagination?

i.e. showing 5-10 out of 100 000 records?

What I'm proposing is to use totalRecords = '?' in the query to specifically ask the server to compute the total number of records.

With the current API: start=0&count=5 # Store computes total # records and sends to onBegin() start=10&count=5 # Store computes total # records and sends to onBegin()

The problem here is when is the total # of records supposed to be computed, each time ???

New API: start=0&count=5&totalRecords=? # Returns records 0-5 + totalRecords=100 start=10&count=5 # Returns records 5-10

comment:4 Changed 11 years ago by Jared Jurkiewicz

Resolution: wontfix
Status: reopenedclosed

You can get them. The widget needs to pass an obBegin handler. The onBegin is always called before any data is returned. Therefore, you always have access to knowing the total size in that situation.

And yes, you want to leave determining thte total records to each call, because it *can* change. Nothing says the serverside couldn't cache the count for return each time and only recompute it if necessary (Eg, users change it by adding/removing records).

Consider a massively multi0user app with a table with users adding and deleting records regularly. the totalRecords will be changing dynamically during use, hence why having a callback that always gets the current record size is valuable.

Closing this ticket again. The function requested already exists in the API definition.

comment:5 Changed 11 years ago by Jonathan Bond-Caron

Please consider a "refresh button" on a UI navigation control where the user specifically asks for a refresh of the data (server side).

The server may cache the count of records, in my use case a snapshot isolation of the data where the user *does not always see the most current data*.

The data API *is incomplete* with respect to pagination but if it's "wontfix" fine.

Note: See TracTickets for help on using tickets.