Secondary separate data storage for old closed tasks for "action diary" (analytics / statistics)

[digitalethics]

It would be great to add a function to allow exporting and permanently storing closed tasks in a database. Completed tasks can be used pretty much as short, itemized reviews of one's daily routines and reading them in retrospect makes them ideal candidates for an action diary.

[nekohayo]

So as I understand it, some sort of split-off separate tasks XML storage for closed tasks. Even if they have been deleted by the user?

One of the reasons why there is a delete function (and a cleanup function) in addition to being able to "close" tasks by marking them "Done" or "Dismissed", is for performance. I accomplish about 150-300 tasks per month, and while that might not seem like a lot, I can guarantee you that it becomes a performance problem over the years because you end up with huge data files (filled with crap that you no longer need anyway).

What I can see, however, is the need for a lightweight task "statistics" storage mechanism (i.e. something that doesn't store the whole contents, just the task IDs, statuses and dates), to be able to look back and know how many tasks were created, done, dismissed, deleted each month and to be able to easily crunch those numbers over the span of many years (analytics would also open up the path for "gameification" features, issue #435). I don't know if this was what the Hamster plugin was about, or if this would need to be a completely new standalone plugin to be designed.

[johnnybubonic]

(responding to @nekohayo 's request for review in IRC)

Hrmmm. A separate XML document would be the way to go, you would want the user to easily clean it up themselves without going through the XML itself. But I'd make it a user preference e.g. "Archive deleted tasks? y/n" sort of thing. I mean technically, if you're storing only the ids, statuses, and dates, that's small enough amount of data for a sqlite DB or something even. Heck, a CSV would even suffice since it'd be such a(n intentionally) lossy operation in terms of trimming data.

I think the "graveyard", as I guess you could call it, should definitely not be parsed though. That should be up to the user to do. Whether it's XML, or a sqlite DB, or a CSV, whatever. If it's a CSV or some sort of DB, you can append the newly deleted task without even parsing the existing contents. With a separate XML document, you'd have to read in the entire file first to add new XML objects.