Upgrading to 3.0 went 99.9% well

[gour]

Hello!

After seeing a lot of discussion about how 2.6.2-->3.0 upgrade created many problems, I'd like to share my experience…

1. 99.9% of my tasks were successfully migrated after I followed this procedure. There was just a warning about some start/stop dates and the tasks with the next tag got due date for yesterday when I did convert.
2. my integration script using tasklib still does work.
3. tw-3.0.x does work within taskshell

Before migration, I was aware about situation in regard to taskd and I am patient to see some new solution to emerge.

I am also pleased that openSUSE Tumbleweed did not rush with upgrade although being rolling release and provided 3.0.2.

The only issue I have is performance-wise (#3307)...My old data had 32M big completed.data and now my database is big:

$ ll *.sqlite3
-rw-r--r-- 1 gour gour 34M tra  28 08:26 taskchampion.sqlite3

although I do not have much tasks:

[...]
104 tasks

$ waiting
[...]
7 tasks

$ blocked
[4 tasks]

so I wonder whether you will recommend me to re-enter all the scratch and by sacrificing old history to improve performance?

$time task burnodown.weekly
[...]
Executed in  169.40 secs    fish           external
   usr time   57.64 secs  165.00 micros   57.64 secs
   sys time  111.58 secs  180.00 micros  111.58 secs

[gour]

The only issue I have is performance-wise (#3307)...My old data had 32M big completed.data and now my database is big:

$ ll *.sqlite3
-rw-r--r-- 1 gour gour 34M tra  28 08:26 taskchampion.sqlite3

although I do not have much tasks:

It looks one has to wait for #3399...

[...]
104 tasks

$ waiting
[...]
7 tasks

$ blocked
[4 tasks]

so I wonder whether you will recommend me to re-enter all the scratch and by sacrificing old history to improve performance?

$time task burnodown.weekly
[...]
Executed in  169.40 secs    fish           external
   usr time   57.64 secs  165.00 micros   57.64 secs
   sys time  111.58 secs  180.00 micros  111.58 secs

[djmitche]

From what I read, your DB size went from 32M (.data files) to 34M (.sqlite3) - is that correct? I'm actually pretty pleased with that, as the new data storage basically stores everything twice (once as an operation and once as a task property).

Regarding the burndown times, yes, re-importing would be one way to get that to execute in a reasonable time. The task purge support will also work, but isn't available yet. Does applying a filter help at all? Something like task burndown.weekly modified.after:-1y?

[gour]

From what I read, your DB size went from 32M (.data files) to 34M (.sqlite3) - is that correct? I'm actually pretty pleased with that, as the new data storage basically stores everything twice (once as an operation and once as a task property).

Yes.

Regarding the burndown times, yes, re-importing would be one way to get that to execute in a reasonable time. The task purge support will also work, but isn't available yet.

OK.

Does applying a filter help at all? Something like task burndown.weekly modified.after:-1y?

Yes, it does.

$ time task burndown.weekly modified.after:-1y
Executed in    2.46 secs    fish           external
   usr time    0.92 secs  204.00 micros    0.92 secs
   sys time    1.30 secs  121.00 micros    1.30 secs

[djmitche]

That's good news! I wonder if the burndown is processing a whole bunch of data it never actually displays?