It's all about the answers!

Ask a question

Unable to query more than 1K workitems using REST


Radha Nagaraja (1558) | asked Jul 10 '14, 12:41 a.m.

Querying Wrokitems in RTC using REST APIs:

With OSLC v2.0

when we get the query list using REST, only the URI with Query ID’s is listed and not the complete details of the query.

But when we try to get the details of the query with the result query URI returned, it throws 406 Not Acceptable response.

With OSLC v1.0

When we try to get the query result total count, it returns only 1000 even if it has more workitems. Also it doesn’t return the next page URL to traverse through the next list.


Any hints how to proceed here will be of great  help.

Comments
Radha Nagaraja commented Jul 10 '14, 12:43 a.m.

I've already seen that the display query limit option on RTC admin page which can be changed from 1000 to any other number.
But I do not know it is has any impact on REST querying. Even if so, is there an adverse effect of changing the count to a bigger number in RTC?


Rohit Balduwa commented Jul 10 '14, 12:49 a.m. | edited Jul 10 '14, 12:50 a.m.

Hi
Go to the below location:
https://<<hostname:port>>/ccm/admin#action=com.ibm.team.repository.admin.configureAdvanced

Search for 'Maximum Query Result Set Size', you can edit the value from default1000 to 1500 or 2000.

Yes, there will be impact on the performance if you set high range of query result set.

I am not sure of the impact on REST querying.


Radha Nagaraja commented Jul 10 '14, 1:02 a.m.

Hello Rohit,

Thanks for the info on performance.
Like I mentioned, even if the maximum limit is changed to a bigger number, there is no way to recursively get all workitems beyond the defined RTC limit.
Hence changing it to a bigger number is like pushing the problem to a later time and not a solution for us unfortunately :(

Regards,
Radha


Vivek Pandey commented Feb 17 '15, 10:56 p.m. | edited Feb 18 '15, 8:31 p.m.

 Hi Radha,


Did you find workable resolution to overcome limit of 1000 WIs in query result set through REST ? 


Radha Nagaraja commented Feb 18 '15, 3:09 a.m.

hello Vivek,
We have not solution for REST. What we intend to do is to automate csv export feature of RTC for queries and use the output for processing further.

Accepted answer


permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 18 '15, 8:30 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
This limitation is being removed in 6.0.   See the following work item for details:
Remove the limit on OSLC 1.0 query results and ignore the “Maximum Query Result Set Size” limit for calls from QP (336705)
Radha Nagaraja selected this answer as the correct answer

Comments
Radha Nagaraja commented Feb 19 '15, 1:23 a.m.

Thanks for the good news Goeff.

3 other answers



permanent link
Sian O'Briain (35921) | answered Sep 22 '15, 5:15 a.m.
Just wondering if this enhancement will also include results obtained by using oslc_cm.query e.g. at the moment I am getting paginated results and using the 'next' link, but once the startAt property gets to 1000 it stops no matter what my pageSize is.

https://jazz_instance/ccm/oslc/contexts/project_uuid/workitems?oslc_cm.pageSize=50&oslc_cm.query='my_query'

permanent link
Vivek Pandey (4321538) | answered Feb 26 '15, 5:13 a.m.
 Thanks Geoff !

permanent link
Eric Jodet (6.3k5111120) | answered Jul 10 '14, 3:54 a.m.
JAZZ DEVELOPER
 Hello Radha,
possibly use pagination:
https://jazz.net/wiki/bin/view/Main/WorkItemAPIsForOSLCCM20#Pagination

Hope it helps,
Eric

Comments
Radha Nagaraja commented Jul 10 '14, 4:18 a.m.

hello Eric,

Thank you for the response.
We are already doing paging to get results in chunks of 50's until 1000. But the problem if we there are more than 1000 workitems resulting from the query, the response received is listing only for 1000 workitems. Actual count of workitems is not returned.

Regards,
Radha


Eric Jodet commented Jul 10 '14, 4:38 a.m.
JAZZ DEVELOPER

OK,

It might help you overcome your issue, and contains links to OSLC spec

Eric 


Your answer


Register or to post your answer.