• Glossary
  • Support
  • Downloads
  • DataStax Home
Get Live Help
Expand All
Collapse All

Developing applications with DataStax drivers

    • Getting started
    • Best practices
    • Connecting to the database
      • Connecting to DataStax Astra databases
      • Authentication in DataStax drivers
      • Using SSL in DataStax drivers
      • Load balancing with DataStax drivers
      • Connection pooling
      • Retry policies
      • Reconnection policies
      • Execution profiles
    • Submitting queries
      • Working with multi-workload clusters
      • Using DSE Search with the DataStax drivers
      • Submitting DSE Graph queries with the DataStax drivers
      • Result paging with DataStax drivers
      • Synchronous and asynchronous query execution
      • Managing concurrency in asynchronous query execution
      • Speculative query execution
      • Query idempotence
      • Driver metrics
      • Object mappers in DSE drivers
      • Query timestamps
    • Error handling
      • Server errors
      • Client errors
    • Example applications
      • Connecting to Astra
      • Executing CQL statements
      • Executing bound statements
  • Developing applications with DataStax drivers
  • Submitting queries
  • Result paging with DataStax drivers

Result paging with DataStax 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.

Result paging example
Figure 1. 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.

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.

Table 1. Result paging for drivers

C/C++

C#

Java

Node.js

PHP

Python

Ruby

Submitting DSE Graph queries with the DataStax drivers Synchronous and asynchronous query execution

General Inquiries: +1 (650) 389-6000 info@datastax.com

© DataStax | Privacy policy | Terms of use

DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries.

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries.

Kubernetes is the registered trademark of the Linux Foundation.

landing_page landingpage