Skip to content

fix: compute totalPages from unpaginated count query#106

Open
temrjan wants to merge 1 commit into
mts-ai:mainfrom
temrjan:fix/pagination-total-pages-count
Open

fix: compute totalPages from unpaginated count query#106
temrjan wants to merge 1 commit into
mts-ai:mainfrom
temrjan:fix/pagination-total-pages-count

Conversation

@temrjan

@temrjan temrjan commented Mar 25, 2026

Copy link
Copy Markdown

Summary

Fixes #103totalPages always returns 1 regardless of actual row count when using page[size] pagination.

Root cause: get_collection() in orm.py builds a query with LIMIT/OFFSET (pagination), then passes the same query to count(). Since count() wraps the query as a subquery, the LIMIT caps the row count to at most page_size, so totalPages = ceil(page_size / page_size) = 1.

Fix: Build a separate count query with only filters and joins (no size/number pagination params). This ensures count() returns the total number of matching rows across all pages.

Before: GET /items?page[size]=10  →  count=10, totalPages=1  (11 items in DB)
After:  GET /items?page[size]=10  →  count=11, totalPages=2  (correct)

Test plan

  • Existing tests are unaffected — they either don't use pagination or don't have more items than page size
  • Could not run tests locally due to FastAPI version incompatibility (field_annotation_is_sequence removed in latest FastAPI) — please verify in CI

🤖 Generated with Claude Code

The objects_count query reused the same SELECT that already had
LIMIT/OFFSET applied, so count() always returned at most page_size
rows, making totalPages always 1 regardless of actual row count.

Build a separate count query with only filters and joins (no
pagination) so that totalPages reflects the true number of pages.

Closes mts-ai#103

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant