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

Answer the Unresolved Decision

1. Providing rowsNumber for a cursor backend
   • QTable’s pager needs a total row count to calculate the number of pages. A cursor strategy can still supply this by exposing a lightweight /count endpoint that returns an approximate or exact total.

     GET /api/items/count
     { "total": 12456789 }

   • For very large tables, a full COUNT(*) can be expensive. Use a dedicated counter table or a materialized view that is updated on inserts/deletes. The counter can be refreshed asynchronously.
   • Send the total as rowsNumber in the same response that contains the first page. Subsequent pages can reuse the same value; if the count changes, the pager will automatically recalc.
2. Customising the pager to a Next/Previous UI
   • Replace the default QPagination slot with a small component that only shows Next and Previous buttons.

     <template #pagination>
       <div class="flex items-center">
         <q-btn flat icon="chevron_left" @click=>"prev()" :disabled=>!hasPrev>
         <span class="mx-2">Page {{ page }} of {{ totalPages }}</span>
         <q-btn flat icon="chevron_right" @click=>"next()" :disabled=>!hasNext>
       </div>
     </template>

   • Maintain the pagination object’s page and rowsPerPage fields so that Quasar’s reactivity still works. Store the cursor token in a hidden field (e.g., pagination.cursor) that is passed back to the server.
   • Because the UI no longer shows page numbers, you can optionally display a simple indicator or hide it entirely. The key is that the component still emits the same event shape expected by @request.
3. Translating @request payloads to cursor queries
   • When pagination.page === 1, the handler should ignore pagination.cursor and issue a query that starts from the first record according to the current sort/filter.
   • For subsequent pages, the handler reads pagination.cursor (a base64‑encoded composite key of the last row from the previous page). It uses that as the WHERE condition for the next set of rows:

     SELECT * FROM items
     WHERE (sortKey, id) >= :cursor
     ORDER BY sortKey ASC, id ASC
     LIMIT :rowsPerPage;

   • If the cursor is missing or stale (e.g., the underlying row was deleted), fall back to the offset strategy for that request:

     SELECT * FROM items
     ORDER BY sortKey ASC, id ASC
     LIMIT :rowsPerPage OFFSET :((page-1)*rowsPerPage);

   • After fetching a page, generate a new cursor from the last returned row and embed it in the response:

     {
       rows: [...],
       rowsNumber: total,
       cursor: encodeCursor(lastRow)
     }

   • Store the new cursor in pagination.cursor before emitting @request again. This keeps the client stateless beyond the hidden field.

Practical Verification Steps

• Implement a mock backend that returns rowsNumber and a cursor token for page 1.
• Use the custom Next/Previous pager and verify that clicking Next updates pagination.cursor and fetches the next slice.
• Simulate a cursor invalidation by deleting a row between requests and confirm the handler falls back to page 1 without breaking the UI.
• Measure response times for both offset and cursor queries on a 10M‑row dataset; cursor queries should be noticeably faster when concurrent inserts are happening.

Assumptions & Uncertainty

• Quasar version 2.x, Vue 3, and the developer can modify QTable slots.
• The backend can expose a lightweight count endpoint or maintain a counter table.
• Cursor tokens are stable; using mutable columns (e.g., updated_at) can invalidate them.
• If the total row count is highly volatile, consider disabling page navigation until the count is resolved.