OSLC pagination in IBM RQM is not working as expected
Hello Everyone,
2 answers
OSLC paging is, in general, problematic for a number of reasons.
The OSLC specification https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/oslc-core.html defines
oslc.pageSize
as having units of number of RDF statements, not number of resources:
When responding to a request that includesoslc.pageSize
in the URI, a server MAY divide the response into a number of pages and use the value as a hint about the maximum number of RDF statements to be included in each page. Servers MAY return pages containing more or fewer RDF statements than specified. [CORE-29]
oslc.pageSize
as the number of resources and include the LDPC in each response for practical reasons of supporting paginated query results. However, in doing so, they are not in compliance with the OSLC Core specification. Which means that clients relying on this are dependent on non OSLC defined tool-dependent behaviours.
These issues are discussed at https://github.com/oslc-op/oslc-specs/issues/169.
Comments
Interesting - thanks. I was trying to point out in my answer how to retrieve all pages, I think you're saying that the counting of entries in a result page may not align to the number of actual result resources that are in the total results, and to retrieve all the results pages and combine them to count the total.
Hi Jyoti
Comments
Hello Ian and David,
You don't need to use - probably stronger than that mustn't - use oslc.page= - the first query always gets the first page (of whatever size the server delivers) and the results contain an oslc.nextPage URL for the next page. BTW you mustn't modify this URL, it is server generated and will simply return the next page.
1 vote
Thank you Ian. Now I am able to get all data. Instead of 'rqm_qm.pageNum', I was using 'oslc.page'.
I hope you're getting your example of the next iteration query from the results for each page and not modifying or constructing this URL because constructing URLs might stop working when your server is updated to a new version. Using the oslc:nextPagein from the results is immune to server-side implementation changes between versions which might change how the URL is constructed by the server.
I hope you're getting your example of the next iteration query from the results for each page and not modifying or constructing this URL because constructing URLs might stop working when your server is updated to a new version. Using the oslc:nextPage from the results is immune to server-side implementation changes between versions which might change how the URL is constructed by the server.