Skip to content

fix: return full pagination object in execute_query responses - #58

Merged
fuleinist merged 3 commits into
TabularisDB:mainfrom
fuleinist:fix/query-pagination-contract
Aug 2, 2026
Merged

fix: return full pagination object in execute_query responses#58
fuleinist merged 3 commits into
TabularisDB:mainfrom
fuleinist:fix/query-pagination-contract

Conversation

@fuleinist

Copy link
Copy Markdown
Collaborator

Stacked on #57 — this branch is based on fix/get-tables-parallel-describe. Only the top commit (fix: return full pagination object) is new; the diff shrinks to a single commit once #57 merges.

Summary

The Tabularis app (0.17+) deserializes execute_query results into a QueryResult whose Pagination struct requires page, page_size, total_rows (optional) and has_more (src-tauri/src/models.rs). The plugin only sent:

"pagination": {"next_token": "..."}

so the app rejected every query response with missing field \page`— and after patching that,missing field `page_size`, then missing field `has_more``. Query results never rendered in the UI.

Changes

  • items_to_response now always emits a complete pagination object:
    • page — request's page param (default 1, new extract_page helper)
    • page_size — request's limit, falling back to the returned row count
    • total_rowsnull (DynamoDB cannot cheaply count a filtered result)
    • has_more — existing next_token/truncation logic, unchanged
    • next_token — preserved alongside for resume
  • Aggregate responses (COUNT/SUM/...) keep pagination: null, which the app's Option<Pagination> accepts.
  • Regression tests: pagination shape, app-contract fields, extract_page defaults.

Test plan

  • cargo test — 178 passed (3 new)
  • cargo clippy — clean
  • End-to-end against the real app + a live AWS account: query results render, paging works

No credentials, endpoints, or account-specific data included in this change.

Made with Cursor

Made with Cursor

Chris Chen and others added 3 commits August 1, 2026 23:14
get_tables issued DescribeTable serially for every table returned by
ListTables. On AWS accounts with hundreds of tables this took over a
minute (~300ms per describe), exceeding the GUI's connection timeout
and failing the initial connection.

Describes now run with bounded concurrency (16 in flight via
buffer_unordered) and results are re-sorted alphabetically to preserve
ListTables ordering. Measured on an account with 400 tables: 75s -> 7s,
with full metadata (item_count, table_size_bytes, table_status)
preserved.

Co-authored-by: Cursor <cursoragent@cursor.com>
The Tabularis app deserializes query results into a QueryResult whose
Pagination struct requires `page`, `page_size`, `total_rows` (optional)
and `has_more`. The plugin only sent `pagination: {"next_token": ...}`,
so the app rejected every query response with "missing field `page`"
(then `page_size`, then `has_more` as each was worked around).

items_to_response now always emits a complete pagination object:
- page: request's `page` param (default 1)
- page_size: request's `limit`, falling back to returned row count
- total_rows: null (DynamoDB cannot cheaply count a filtered result)
- has_more: existing next_token/truncation logic
- next_token: preserved alongside for resume

Stacked on TabularisDB#57.

Co-authored-by: Cursor <cursoragent@cursor.com>
CI was failing because cargo fmt --check found formatting differences
on the sort_by line. Reformat to match rustfmt expectations.
@fuleinist
fuleinist merged commit d9509d6 into TabularisDB:main Aug 2, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant