Community
Participate
Working Groups
A complaint I have recieved by projects that I mine is the process of getting one bug at a time from the repository when I want a set of reports. This is also a performance issue for applications such as mine. Could you please add a method that takes in a list of report ids (such as returned by a search collector) and returns the RepositoryTaskData items? To make the repository admins happy the method would need to make a single call to the server (i.e. the method should not just loop over the report id list and call getTaskData(id) - I'm already doing that and the admins grumpy). Maybe a method looking like : client.getTaskData(List<String> reportIds);
We could likely speed up a few operations (such as synchronization) if we just hit the search once per set of tasks rather one by one. It will require some changes to our api. I'll try to get to this for 2.0. At the least headless support could be added.
Example Query: /show_bug.cgi?ctype=xml&id=23&id=24&id=25
Created attachment 61708 [details] Use single request patch Use single request if supported.
Created attachment 61709 [details] mylar/context/zip
Created attachment 61710 [details] mylar/context/zip
Mik, Eugene, you may want to have a look over suggested changes, specifically to SynchronizeQueryJob, SynchronizeTaskJob, and api in ITaskDataHandler. I didn't look into Jira or Track's ability to support single request for multiple task data. Still some error handling improvements required such as fail over to individual task download in case of exception during multi download in the two synch jobs.
I will not be able to review today, but feel free to point me at it in person tomorrow.
Since my patch is getting stale I've committed the bugzilla client side support for this so that John can use it headless. We can discuss the proposed changes to the tasks api during the next mylar conference call. John, I've added Map<String, RepositoryTaskData> getTaskData(Set<String> taskIds) to BugzillaClient. Pass in a set of task ids and you'll get back a map of id -> taskdata. Note to self: Enable unit test in BugzillaQueryTest once ITaskDataHandler api updated.
Great. Thanks.
We should look into refactoring part of the synchronization API for 2.0M3. Trac and JIRA return the complete task information for each query result and not just the ids. With the current implementation this data is downloaded again when all changed tasks are synchronized. Eugene also suggested to add an option to always download task data for certain queries to support working offline.
(In reply to comment #10) > Eugene also suggested to add an option to always download task data for certain > queries to support working offline. Yea, that hit me really bad on my last trip. I don't know what Mylar is downloading, but I wasn't been able to open any new/incoming tasks for offline reviewing.
The connector that I am writing also returns the complete task information upon a query and therefore it is downloaded twice with the current implementation. It would be nice if the data could be saved and not downloaded if the repository supports this.
BTW, I should say that connector I write does the same. So, it seems like Bugzilla is nearly the only one that don't return complete task data.
Will refactor api for M3 as per conference call. AbstractRepositoryConnector.performQuery() should update task data directly (rather than launching additional jobs to retrieve task data for each hit). In doing we can also address handling of synch timestamp (bug#176934).
Committed first pass. ITaskDataHandler now AbstractTaskDataHandler. Added getTaskData method that takes a set of ids and returns a set of retrieved data. The only problem I see thus far is the inability to set error status on a per task bassis.
The default implementation of AbstractTaskDataHandler.getTaskData() should not return null. It should iterate over the tasks and download the task data for each individual task or throw an OperationUnsupportedException().
Yes, I considered both suggestions and unless we start passing the set of task objects to this new data handler method we can't set the error status on individual tasks. So for that reason I backed out and implemented as it is now. I'll have another look today though with fresh eyes.
I am not convinced that the new API is better for repositories that do not support fetching multiple tasks at once since it delays completing the synchronization for each task until the task data for all tasks has been downloaded. With the old API single tasks would complete as soon as the data became available. It also makes the API of AbstractTaskDataHandler more complicated. My suggestion is to add a AbstractTaskDataHandler.canGetMultiTaskData() method that returns false by default. SynchronizeTaskJob should use the old implementation that synchronized each task individually in that case and only use getMultiTaskData() when available. I wouldn't worry about the error status too much and just set it on all tasks like it is done now.
(In reply to comment #18) > I am not convinced that the new API is better for repositories that do not > support fetching multiple tasks at once since it delays completing the > synchronization for each task until the task data for all tasks has been > downloaded. Yes, this bothers me too. > My suggestion is to add a AbstractTaskDataHandler.canGetMultiTaskData() method > that returns false by default. SynchronizeTaskJob should use the old > implementation that synchronized each task individually in that case and only > use getMultiTaskData() when available. Done.
Rob, please consider making AbstractTaskDataHandler.getMultiTaskData() throw UnsupportedOperationException by default. Having an API fail siliently can have funny effects.
Done.
Marking resolved.
