Automatically installs Taskwarrior, Taskserver (TODO: and Timewarrior). This project aims to support automated installation of all Taskwarrior hook scripts, configuration flavours etc. with a single command.
GNU Affero General Public License v3.0
17
stars
7
forks
source link
Make task custom sort index storing complexity semi-O(1) #8
<p>Currently, the <code>cSort</code> attribute (UDA) of all tasks are modified if a single task is put on top of the list, (that task gets <code>cSort=1</code> and all other task <code>csorts</code> get incremented by 1). File backlog.data stores all versions of a task, so if a task is created or changed, that task is added at the end of backlog.data. Hence, the <code>cSort</code> index storing inflates the backlog to over 34 mb, 24000 lines with 800 tasks within a few hours.</p>
As a symptom-remedy, I scan the backlog for tasks that only contain a modification of cSort, and then merge the two:
The first of the two tasks in backlog (based on modification date) gets copied, but it's cSort is updated/changed with the cSort of the last modified task.
This ensures the backlog still only contains the actual manual changes of the user, in chronological order, but with the most recent cSort value such that it does correspond with the most recent task custom sort order.
The solution that was suggested to me was to not number the tasks 1..n tasks, but to spread them uniformly over the whole range of integer values allowed by taskwarrior. Then if you need to put the last task to the 2nd place, you put it exactly between the first and second value. This way you do not need to update the entire second to last task.
E.g.:
In stead of csorts: 1,2,3,4,5>1,3,4,5,2 write it as: 1,100,200,300,400,500>1,50,100,200,300,400,500
If you are mostly swapping blocks instead of single tasks, don't write the position of the task in cSort, but write the task id or uuid that points to the next task, in cSort. This way you need to only modify 2 or 4 tasks if you want to move a block of 100 tasks.
One should think what happends if the integer spaces between certain tasks are filled in applying the former, and what happends if a task gets purged in the latter. Preferably test these scenarios.
As a symptom-remedy, I scan the backlog for tasks that only contain a modification of
cSort, and then merge the two:cSortis updated/changed with thecSortof the last modified task.This ensures the backlog still only contains the actual manual changes of the user, in chronological order, but with the most recent
cSortvalue such that it does correspond with the most recent task custom sort order.Problem:
Modifying the backlog.data file directly is considered bad protocol according to experienced taskwarrior users:
https://groups.google.com/forum/#!topic/taskwarrior-user/uD18qnlAgCg
Solutions given:
The solution that was suggested to me was to not number the tasks 1..n tasks, but to spread them uniformly over the whole range of integer values allowed by taskwarrior. Then if you need to put the last task to the 2nd place, you put it exactly between the first and second value. This way you do not need to update the entire second to last task.
E.g.:
In stead of csorts:
1,2,3,4,5>1,3,4,5,2write it as:1,100,200,300,400,500>1,50,100,200,300,400,500If you are mostly swapping blocks instead of single tasks, don't write the position of the task in cSort, but write the task id or uuid that points to the next task, in cSort. This way you need to only modify 2 or 4 tasks if you want to move a block of 100 tasks.
One should think what happends if the integer spaces between certain tasks are filled in applying the former, and what happends if a task gets purged in the latter. Preferably test these scenarios.