Skip to main content

Paginated Business Query

Evidence status: API and intent-order review only. The current Java Golden Path is blocked before runtime execution, so page boundaries, stable ordering, scope, and limits still require provider-backed tests.

Problem​

Return a bounded result window without loading the full business dataset into application memory.

Java Path​

Apply deterministic ordering before pagination. Trusted tenant and permission scope is imposed by runtime policy from UserContext; the optional merchant filter below is business narrowing, not the security boundary:

Q.orders()
    .filterByMerchant(ctx.getMerchant())
    .orderByCreateTimeDescending()
    .page(2, 20)
    .comment("Query merchant orders")
    .purpose("Render page two of the order list")
    .executeForList(ctx);

Current Java documentation defines page(2, 20) as page two with 20 rows and page numbers starting at one. It also supports zero-based result windows:

Q.orders()
    .offset(20, 10)
    .comment("Query orders")
    .purpose("Load a ten-row result window from index twenty")
    .executeForList(ctx);

Generated filters and ordering methods are model-specific. Read the request source before adapting the example.

Verification​

  • Insert enough records to span at least three pages.
  • Give records equal primary sort values and add a stable secondary order if the generated API supports it.
  • Confirm adjacent pages do not overlap or omit records in a stable dataset.
  • Confirm tenant/permission constraints apply before paging.
  • Confirm page-size limits cannot be bypassed by untrusted input.
  • Test empty, first, last, and beyond-last pages.

Common Failure Modes​

SymptomFix
Rows move between pagesAdd deterministic ordering and account for concurrent writes.
Cross-tenant rows appearApply trusted context scope before pagination.
Large page exhausts memoryEnforce an application maximum page size.
UI count disagreesRun count and data queries with the same trusted constraints.

References​