[closed] RTC returns only 50 work items when it is accessed though OSLC query
Takehiko Amano (1.3k●37●41)
| asked Aug 22 '12, 3:39 a.m.
JAZZ DEVELOPER closed Jul 13 '23, 1:27 p.m. by Ralph Schoon (63.6k●3●36●46)
Hi,
I wanted to change the number of records returned from RTC server when it is accessed via OSLC. It seems default value is 50. So I added oslc.paging and oslc.pageSize. https://localhost/ccm/oslc/contexts/<project_uuid>/workitems?oslc.paging=true&oslc.pageSize=200&oslc.select=dcterms:identifier But still it returns only 50 records. if I change the value to oslc.pageSize=10, the query returned 10 records. So this parameter is working for less than 50. I did some experiments:
I wonder if this is a spec or bug. I prefer not to use oslc:nextPage ( I understand there is overhead in the client side for large query though). |
The question has been closed for the following reason: "The question is answered, right answer was accepted" by rschoon Jul 13 '23, 1:27 p.m.
Accepted answer
This is a restriction on all CLM tools where the Max Feeds Per Page is fixed at 50. Although you can change it through Administrator Page (Advanced Settings --> Max Feed Entries/Page). But I would suggest that you iterate through all the pages to get all the entries. Every Page you get has a link to the next page (if any) that has next set of entries.
Takehiko Amano selected this answer as the correct answer
|
4 other answers
Just to add a note to this thread, I believe you can override the default number of query results by adding an optional qualifier at the end of the URL. I've done this with REST API queries and not really with the OSLC ones, but I assume it works for both protocols. Just tack on "&size=###" to override the number of returned results. For example: |
|
Self post. I think this is a defect, I created this one.
Setting oslc.pageSize over 100 does not work when querying workitems through OSLC (228310) Please use this workitem when users hit this problem. Comments I think IBM uses paging as a defensive measure against a client dragging out the entire data set and clobbering the server. Been barking up this tree for some time and gave up. Now I have a small set of logic that looks for next page and iteratively calls the server for the next batch of material, appending it to a big list (in perl) as we go.
Yes, that is what I'm doing now in my Perl module. It is not difficult.
|
I hit problems using the next page link. I was requesting json format and when I navigated to the next page I would get back xml which seemed to cause problems with my script accept headers. In the end I started using the _startIndex and oslc_cm.pageSize paramaters and just add on the page size through each loop. This seems to work fine but if anyone can point out any flaws with this approach please let me know. No result token so hope it is ok
|
