Result paging with Cassandra drivers
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.
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.
|
The paging state can be forged to access different partitions, so it should not be exposed in plain text in unsafe environments. |
The C#, Java, Node.js and Python drivers provide a way to traverse the whole result set transparently by triggering background fetches as the iteration crosses page boundaries.
