Bugzilla – Full Text Bug Listing
| Summary: | Add caching of issue fields and available actions | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> |
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | 2.2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 207047 | ||
| Bug Blocks: | |||
|
Description
Eugene Kuleshov
We should update the information each time we synchronize a task but we could use the cached information when opening the editor while synchronization is running in the background. Permissions of a JIRA user can change anytime so it should be easy to update the cached information by synchronizing the task. (In reply to comment #1) > We should update the information each time we synchronize a task That doesn't make sense. The reason to cache this stuff is to skip round trips to server (at least 2 of them) when synchronizing task. > but we could use the cached information when opening the editor > while synchronization is running in the background. That is something along the lines I've tried, but it don't work too well. So, I dropped idea of using different data sources when showing editor. > Permissions of a JIRA user can change anytime so it > should be easy to update the cached information by synchronizing the task. I was thinking to flush cache when refreshing repository attributes. > > We should update the information each time we synchronize a task > That doesn't make sense. The reason to cache this stuff is to skip round trips > to server (at least 2 of them) when synchronizing task. I think it doesn't matter that much how long task synchronization that takes as long as the editor opens quickly from offline task data (i.e. whatever is received when running a query). > > but we could use the cached information when opening the editor > > while synchronization is running in the background. > That is something along the lines I've tried, but it don't work too well. So, I > dropped idea of using different data sources when showing editor. Why? > > Permissions of a JIRA user can change anytime so it > > should be easy to update the cached information by synchronizing the task. > I was thinking to flush cache when refreshing repository attributes. As a user I expect the task to be fully initialized when I do a manual synchronization. (In reply to comment #3) > I think it doesn't matter that much how long task synchronization that takes as > long as the editor opens quickly from offline task data (i.e. whatever is > received when running a query). Editor opens quick enough without any caching, but when 300 jira issues synchronize 30 minutes instead of 10, I think it does matter. > > That is something along the lines I've tried, but it don't work too well. > So, I dropped idea of using different data sources when showing editor. > Why? Because there is no easy way to parametrize synchronization process. > As a user I expect the task to be fully initialized when I do a manual > synchronization. Again, current API don't allow to parametrize synchronization - i.e. full vs. quick. (In reply to comment #4) > > I think it doesn't matter that much how long task synchronization that takes > as > > long as the editor opens quickly from offline task data (i.e. whatever is > > received when running a query). > Editor opens quick enough without any caching, but when 300 jira issues > synchronize 30 minutes instead of 10, I think it does matter. What is the use case for manually synchronizing 300 issues? > > > That is something along the lines I've tried, but it don't work too well. > > So, I dropped idea of using different data sources when showing editor. > > Why? > Because there is no easy way to parametrize synchronization process. I think the patch for bug 161734 which is due to be merged on Monday will introduce the required functionality. It will allow the JIRA connector to create task data from query results. (In reply to comment #5) > What is the use case for manually synchronizing 300 issues? Same as manually synchronizing 5 or 10 issues. When you need to go offline time counts. > I think the patch for bug 161734 which is due to be merged on Monday will > introduce the required functionality. It will allow the JIRA connector to create > task data from query results. That is not the same. When individual task is synchronized or when query hits are downloaded, it kicks full synchronization. Besides, I need to have fully synchronized issue when editor is opened for the first time, otherwise it is not possible to construct its fields and available actions. Also, when editor is refreshed at the end of sync we lose information about incoming changes. (In reply to comment #6) > (In reply to comment #5) > > What is the use case for manually synchronizing 300 issues? > Same as manually synchronizing 5 or 10 issues. When you need to go offline time > counts. From my understanding this won't be necessary when hits are created from task data since all information required for offline work is already there. > > I think the patch for bug 161734 which is due to be merged on Monday will > > introduce the required functionality. It will allow the JIRA connector to > create > > task data from query results. > That is not the same. When individual task is synchronized or when query hits > are downloaded, it kicks full synchronization. That should change with the patch. > Besides, I need to have fully > synchronized issue when editor is opened for the first time, otherwise it is not > possible to construct its fields and available actions. Why can't we use the cached information here? > Also, when editor is > refreshed at the end of sync we lose information about incoming changes. This could be tricky to get right. (In reply to comment #7) > From my understanding this won't be necessary when hits are created from task > data since all information required for offline work is already there. That is not correct and that is why those additional calls are required. Information about which fields are editable and what actions are allowed for given issue can't be retrieved from the rss feed and it require 2 separate calls to soap api to get it. > Why can't we use the cached information here? a) it is not correct (according to you), b) it will change after sync, hence changing how editor look quite a lot Anyways, it is working more or less ok and the only reason I thought for use caching is to speedup synchronization. If you think it is bad idea, that we should punt on it. > > From my understanding this won't be necessary when hits are created from task > > data since all information required for offline work is already there. > That is not correct and that is why those additional calls are required. > Information about which fields are editable and what actions are allowed for > given issue can't be retrieved from the rss feed and it require 2 separate calls > to soap api to get it. It is true, that the editor might not necessarily display the correct state when first opened but to me that is acceptable for offline work. The actions do not matter in this case since the task won't be submitted while offline. > > Why can't we use the cached information here? > a) it is not correct (according to you), b) it will change after sync, hence > changing how editor look quite a lot Yes, that is the tricky part. > Anyways, it is working more or less ok and the only reason I thought for use > caching is to speedup synchronization. If you think it is bad idea, that we > should punt on it. I think it is a good idea but I would only use the cached information for tasks opened from query hits and update it each time a task is synchronized (since this is the behavior I expect). Let's bring this up on the next conference call to hear other opinions as well. (In reply to comment #9) > It is true, that the editor might not necessarily display the correct state when > first opened but to me that is acceptable for offline work. The actions do not > matter in this case since the task won't be submitted while offline. In my understanding you do need to have real actions even in offline. Because saved task will be sent to server on next sync. The current caching strategy retrieves the actions and editable fields on the first synchronization and on forced synchronizations. This allows fast synchronization of queries and still feels reasonably fast on forced or initial synchronizations. If there are indications of scalability issues we can consider implementing a more sophisticated strategy that uses caching across different issues from the same project. |