Support for CAP reliable paging #4388
Description
Why are you proposing this feature?
Note: In the interest of time, I'm unfortunately recycling the contents of an SAP incident. I apologize that I can't take the time today to rewrite this from using a Fiori Elements example to using a simple sap.m.Table example. That said, the exact same problem will occur with sap.m.Table, as it is the base control used in the Fiori Elements list report example mentioned below. The basic problem is lack of support in UI5 for CAP's reliable paging mechanism, at least as far as we can see.
Thanks for taking a look at this request.
We are developing a List Report application using SAP Fiori Elements with an OData V4 backend service (implemented via SAP CAP). The backend enforces reliable pagination using @odata.nextLink and $skiptoken (with cds.query.limit.reliablePaging: true enabled for stable, token-based pagination). This avoids issues with numeric $skip/$top (e.g., duplicates/missing rows due to concurrent data changes).
However, the Fiori Elements frontend always sends $top and $skip parameters in batch requests (GET SalesOrderList?$count=true&$select=cart_name,client,customer_number,customer_po_number,sales_order,sales_order_status,sport_type,spro_name&$skip=0&$top=400), even for initial loads and growing/scrolling. This conflicts with our backend, which does not expect or handle client-provided $top/$skip (as per OData V4 spec for pure server-driven paging).
As a result:
- Backend may reject or ignore these parameters, leading to inconsistent paging.
- In case of backend pushing the query down to a remote source via SDI, the $skip doesn’t translate to OFFSET equivalent db clauses giving incorrect results or overloading the system (Ticket 27190/2026 has been opened for that)
- We cannot achieve true server-side control without custom frontend hacks which are fragile and not recommended and also not sure if custom coding can restrict top and skip in the OData call.
--- Steps to Reproduce ---
Generate a Fiori Elements List Report app with OData V4 service.
Enable growing table (e.g., “growing”: true, “growingThreshold”: 50 in manifest).
Load the app and inspect network requests → observe $top/$skip in batch calls.
Scroll to trigger more data → subsequent requests still include calculated $skip/$top
How should a possible solution look like?
An option on sap.m.Table (and in Fiori Elements, ideally) to using reliable paging with nextPage and skipToken instead of skip and top.
Are there alternative approaches?
I'm sure there are. There are also workarounds.
Any further information you would like to share?
No.