QTable @request Pagination: Choosing Offset vs Cursor for Large Datasets

Goal

Implement server‑side pagination for a QTable that displays millions of rows. The table must support dynamic sorting and filtering while keeping the UI responsive.

Constraints & Uncertainty

• Quasar’s @request event delivers a pagination object with page, rowsPerPage, sortBy, descending, and filter fields.
• Client‑side pagination requires the full dataset in the browser, which is infeasible.
• Server‑side pagination can be implemented with either offset‑based (LIMIT/OFFSET) or cursor/key‑set approaches.
• The built‑in pager UI is page‑number‑centric; it expects a total rowsNumber to calculate the number of pages.

Unresolved Decision

How to reconcile cursor‑based pagination, which is more efficient and stable under concurrent modifications, with Quasar’s page‑number UI that expects offset‑style navigation?

Questions

1. What strategy allows a cursor‑based backend to supply the rowsNumber required by QTable without re‑implementing the entire pager?
2. Is it possible to customize the QTable pagination component to display a “Next”/“Previous” style UI that works with cursor tokens?
3. When using cursor pagination, how should the @request handler translate the pagination payload into a cursor‑based query, and what fallback exists if the cursor is invalid?