Results and pagination
How DynamoOps pages through Scan, Query and PartiQL results, what the page controls do, how page size affects cost, and how to refresh.
Pages, not offsets
DynamoDB returns results in pages and hands back a continuation key rather than a total count. DynamoOps mirrors that model: each tab keeps the chain of page keys it has seen, so moving back to a visited page is instant and moving forward fetches the next page. Scan and Query use LastEvaluatedKey; PartiQL uses NextToken.
Because DynamoDB cannot report how many pages exist, DynamoOps shows the pages you have visited plus three look-ahead pages while a next page exists. Jumping to a page you have not visited fetches the intermediate pages in sequence and shows “Loading page N…” meanwhile. If the data runs out before the target, the result bar reads “(last page)”.
Controls
| Control | Action |
|---|---|
| « | First page |
| ‹ | Previous page |
| 1 2 3 … | Jump to a visited or look-ahead page; long ranges collapse with an ellipsis |
| › | Next page |
The controls appear only when a next page exists or more than one page has been visited. Pagination state is per tab, so switching tabs never loses your place.
Page size and cost
Page Size in the Filters panel sets the DynamoDB Limit, from 1 to 1000 with a default of 50. A larger page means fewer round trips but more capacity per request and more rows to render.
- For exploring, 50 to 100 keeps the grid snappy.
- For exporting, tick Export entire table in the Export dialog instead of raising the page size; DynamoOps pages at 1000 per request for you.
- Filtered scans may return fewer rows than the page size; the “scanned” count in the result bar shows what you paid for.
Refreshing
🔄 in the toolbar, ⌘+R or executing again re-runs the current mode with the current field values from page 1 and rediscovers columns. To fetch every item behind a query in one go, use Export with “Export entire table”.