I can execute a query via the TFS 2010 API like say:
string wiql = @"SELECT [System.ID], [System.Title]
FROM workitems
order by [System.ID] asc";
WorkItemCollection items = project.Store.Query(wiql);
foreach (WorkItem item in items)
{
///... do stuff
}
To return all the work items - but it appears there is no way to control page size/which page I would like the query to return.
However I have noticed there is a property PageSize on the WorkItemCollection returned from the query method - which some documentation suggests can be set to a value between 50 and 200.
This suggests some kind of virtualzed/paged collection under the hood.
I was wondering if anyone knew how exactly this was implemented and could confirm if:
Executing a query for say all work items in a TFS project collection - which lets say total 100,000 - is it possible to safely enumerate all the work items in the collection returned from a single query, relying on TFS to fetch page after page - or are there some limitations on the total number of results it can handle.
Secondly, if it does work that way (effectively endlessly fetching pages of records until there are no more pages), will fetched pages of work items be cached indefinitely until the WorkItemCollection itself is garbage collected (will I still run into memory issues as I iterate through the collection?) - or are the work items held by weak reference, so they/the page they belong to eventually gets disposed if nothing is referencing those work items any more.
And lastly if these problems do exist, what's the recommended way to work around, would something like this suffice:
- Counting the number of items first, using a count query.
- Executing the query, with page size of say 200, and looping over those 200 work items (index 0..199)
- Saving the index of the item I'm currently "up to" (200), then disposing of the collection.
- Executing the query again, continuing iteration from the index I was up to (200) for another 200 work items (200..399).
Thoughts?