Result paging with DataStax drivers

Large result sets can be divided into multiple pages that the client will fetch in
separate network requests.

Large result sets can be
divided into multiple pages that the client will fetch in separate network requests.

The page size specifies how many rows will be returned at a single time from
the server. With each response, the server returns a paging state which is a binary
token for the next request to indicate where to restart from.

Figure: Result paging example

While the paging API is specific to each driver, they all share a common set of
features:

Paging is enabled by default with options that can be configured.

The page size can be overridden per query, or paging can be disabled for individual
queries.

Result objects provide a way to fetch the next page directly without manipulating
the paging state or re-executing the query explicitly.

The paging state can be extracted from a given result object and reinjected in a
query later. This option is useful if you need to store the state across executions. For
example, in a stateless REST web service, the paging state can be encoded in the link to the
next page to seamlessly navigate to where the user left off.

Note: The paging state can be forged to access different partitions, so it should not be exposed
in plain text in unsafe environments.

Some drivers (C#, Java, Node.js and Python) provide a way to traverse the whole
result set transparently by triggering background fetches as the iteration crosses page
boundaries.