Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

OSLC pagination in IBM RQM is not working as expected

 Hello Everyone,


I wanted to fetch all test cases available in particular project. I am able to get most of test cases, but it is not returning all test cases.

Total Test Cases available in Project:-2744
Return Test Case list size through OSLC :-512(It is default size)

Please find the below OSLC query:-

https://{QM_Domain}:9443/qm/oslc_qm/contexts/{ProjectUUID}/resources/com.ibm.rqm.planning.VersionedTestCase?oslc_config.context={configUUID}&oslc.paging=true&oslc.page=0&oslc.pageSize=100&oslc.orderby=+oslc%3AshortId&oslc.select=dcterms%3Atitle,oslc%3AshortId

Kindly guide, why pagination is not working in this. If there are another ways to achieve it ,kindly suggest.

Thanks and Regards,
Jyoti

0 votes



2 answers

Permanent link

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 includes oslc.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]

The OSLC specification also makes no guarantee about whether any page response is complete. So the only guaranteed way of looking at the returned data is to consume all pages and construct the union model across all those responses.

This makes it especially problematic for querying for resources in a paged manner.
It appears that some tools, like ETM, treat 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.

1 vote

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.

From a pure OSLC aspect, yes. But that's not very useful.

For a query, there might be a large number of results, and the use case might be that a client wants to present each page of results to a user and allow them to navigate to the next page or a previous page. Having to consume all pages before you can do that is terrible for performance, and not kind to the server or the client. If a user is only interested in the first few pages, then having to get all pages for all requests is just inefficient. Sadly, OSLC doesn't define any mechanism to support such a use case.
That's why some applications have diverged from what the OSLC specification has defined to get usable query results pagination.But now that becomes non-conformant and tool-specific. That's why I raised https://github.com/oslc-op/oslc-specs/issues/169.


Permanent link

Hi Jyoti


Each page provides the url the next page in the results using a <oslc:nextPage> tag with a resource URI for the next page - if the page doesn't contain the oslc:nextPage then there are no more pages.

I would remove the &oslc.page=0 - it's possible this is causing your problem by always returning just page 0 (the first page).

While you are asserting a page size 100 in your OSLC Query, the server can ignore that or assert its own page size, that's normal/expected behaviour.

You may be providing the configuration in the headers and you haven't shown what you're using. if the ETM project uses configuration management and you don't provide a configuration with the query then you will get results from the default configuration which could be a completely different number of test cases, i.e. like what you're saying..

HTH
Ian

0 votes

Comments

Hello Ian and David,


I am using the above query for first iteration and for next iteration, I am incrementing 'oslc.page' count value, but no luck, every time it is returning only same 100 data. It is working fine for only 1st iteration and till page size as ''512' .

If I am incrementing 'oslc.pageSize=512', it is returning 512 data, but if increment page size more then this ,it does not work. 

Is there Reportable rest API ,which will return all test cases or test plans. I have tried by changing QM Advanced property ''search result page size' from 512 to 600,but still not giving result 600 test cases. Kindly provide some APIs. 

Thanks and Regards,
Jyoti
 

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.


I suspect that because you're not using the oslc:nextPage URL the server thinks each request is for a new query so returns the first page of this new query, ignoring oslc.page which AFAIK isn't a documented query parameter name.
  
As I already said, the standard doesn't require the server to obey the page size you specify - your code should accept the results the server provides in each page and use the oslc:nextPage URL to collect the pages until there aren't any more.

1 vote

Thank you Ian. Now  I am able to get all data. Instead of 'rqm_qm.pageNum', I was using 'oslc.page'.

Next Iteration query:-
https://{domainName}:9443/qm/oslc_qm/contexts{ProjectUUID}/resources/com.ibm.rqm.planning.VersionedTestCase?oslc_config.context={ConfigContext}&oslc.paging=true&oslc.pageSize=512&rqm_qm.pageNum={Page Count}

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.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: May 27 '22, 5:54 a.m.

Question was seen: 1,345 times

Last updated: Jun 01 '22, 3:28 a.m.

Confirmation Cancel Confirm