It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,844
×471
×8
×7
×6

question asked: May 12 '16, 4:26 p.m.
question was seen: 1,527 times
last updated: May 15 '16, 7:56 p.m.

Related questions

REST API - how page by page loading works in detail? What is result order?

0
Jan Pechanec (13●1) | asked May 12 '16, 4:26 p.m.
We load big number of RTC WorkItems page by page (one page contains 100 records), by following URLs:
  • 1st: jazz/rpt/repository/workitem?fields=workitem/workItem[creationDate > 2013-03-01T00:00:00.000-0500]/(id|creator/(name|userId)|creationDate|summary|description))))&size=100&pos=0
  • 2nd: jazz/rpt/repository/workitem?fields=workitem/workItem[creationDate > 2013-03-01T00:00:00.000-0500]/(id|creator/(name|userId)|creationDate|summary|description))))&size=100&pos=100&ID=XXXXXX
    (id=XXXXXX is from URL given inside 1st response)
  • 3rd: ...
  • ...
Questions:
  1. What is meaning of ID parameter? Does it open an atomic transaction for next calls? Or any other advantage?
  2. What is order of returned WorkItems? What if a new WorkItem is added between 2 HTTP calls - can it shift global WorkItem list so actually some other WorkItem can be then loaded twice (in 2 pages)?
  3. When WorkItem is changed while calling HTTP calls mentioned above - does it return updated WorkItem content? Similar with newly created WorkItem.
Thank you for any info!

Accepted answer

0
permanent link
Donald Nong (14.5k●6●14) | answered May 12 '16, 11:30 p.m.
I'm not an RTC developer so I only state from my experience and observation.

1. The ID should refer to a "query cache". The query should be sent to the database only once, and the server keeps the query result in cache. When you request the next page of the query, the server will pick up items from the cache, not send the query to the database again.
2. The result appears to be order by work item ID - the reportable REST API does not explicitly specify any order parameters. Not sure what you mean by "global WorkItem list". If you mean the result set, it should remain constant, unless (see below).
3. If a work item gets changed, the current attributes are returned when you load the page - it appears that the query cache only holds the work item IDs.
4. If a work item is created after the query is executed, it will not appear in the query result if you refer to the existing query (with the ID).
5. HOWEVER, if a work item is deleted, it will be removed from the query result. I have not done extensive testing to see how it will affect the ordering and pagination of the query result.
Jan Pechanec selected this answer as the correct answer
Comments
Jan Pechanec commented May 13 '16, 3:50 p.m.

Thanks much for quick answer!

  1. "query cache" - sounds good! We load about 150 000 work items (will be even more), but if it caches WorkItemIDs only, it sounds real.
  2. Unfortunately not - it is not sorted by work item ID when I call our URLs mentioned above. But if result set is stable, it is not important then.
  3. I understand, thanks.
  4. Good, thanks.
  5. Ups, it is possible to delete WorkItems? I am not able to delete them... Who can do it? Is it common use case?

Donald Nong commented May 15 '16, 7:56 p.m.

Deleting work items is not a common use case. In fact, many users have a hard time finding out who deleted their work items - currently there is no logging at all. So unless you have a need for such use case, do not give the permission to anybody. By default, no roles have the Delete Work Item permission.

Your answer

Register or 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.