Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-dev] tips on efficent read access to Task attributes

Thanks Steffen,

I've gone with managing the data seperately, and caching ITask wrappers which add the extra info. My tasks grids work much quicker now, and the hard-drive gets a rest.

1) Better from memory footprint standpoint than triggering creation of AbstractTask's attribute map. All the data I'm storing for a task is less than the size of new HashMap(). One time hit of reading all saved atsk data from disk is ok.

2) Can store objects and arrays rather than strings

* Yes an ITaskDataManagerListener notification of editor saves would really help me track changes

* I'm ok with using mylyn jira internal APIs, given JIRA specifics of task data I'm showing in a grid
- When have time will feedback that would be useful to have some name<>id mappings in opposite direction to those currently in JiraClientCache.

By the way:
- The task list has a group for new-unsubmitted tasks, but not for existing tasks with saved (but unsubmitted) task modificaitons.
- This would be useful together with a pop-up menu actions to submit/revert saved but unsubmitted task modifications. (I hacked a crude submit menu action that gives a confirmation dialog showing changed fields to each task. Works well for my extension: edit tasks quicky in a grid, then eye-ball changes as you submit them en-mass)

Thanks,
Mark

Steffen Pingel wrote:
So far I have been able to get attributes from TaskData. While this
works, it is slow and its clear that TaskData isn't intended for
frequent read access to TaskAttributes, so I'd like to find a more
efficient way, that fits with how Mylyn is designed.
- TaskData looks like it is intended to back task editing pages, not
every task show in a grid of 100s of tasks.
- TaskData is loaded from XML every time you ask for it
    
Yes, that is correct. One approach to avoid frequent disc access would be to 
load the required task data objects once, extract the neccessary fields and 
cache them in your own data structure.

  
AbstractTask has an attribute Map, would it a sensible approach be to
put the few values I need to read often there - hoisting them up from
TaskData ?
- If so please advise on how to keep this view of attribute values in-sync
- What listeners and calbacks should I use to faithfully track the real
attribute values
- Idealy I'd like to see saved values (outgoing changes)
    
Please keep in mind that ITask objects are kept in memory and are designed to 
provide the attributes required by the task list. While the attribute map can 
be used to store additional attributes and might work well in this case is 
intended to be used by connectors only. This is discussed on this bug report 
in more detail:

 199818: [api] arbitrary attributes in AbstractTask
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=199818

I would recommend to implement your own data structury that caches the 
relevant information for your view. To keep the data in sync you can register 
an ITaskDataManagerListener using TaskDataManager.addListener(). The listener 
is notified when the task data is updated from the repository. It is 
currently not fired when task data is saved in the editor but that is 
something that we certainly could add. 

I am not sure that there is a way to implement this without using internals at 
the moment. That said I would be interested in improving the API to support 
efficient access to (parts of) task data. Please feel free to file a bug 
report that describes your use case and requirements so we can discuss 
changes to the API further.

Steffen

  


Back to the top