Implement an SQLite cache about todoman HOT 7 CLOSED

I think it's a bad idea to expose SQL queries.

They will only be used internally. The sorting command and all the cli commands in general will remain the same.

from todoman.

I'm currently working on this, and re-writing the whole model backend, so I'd suggest not doing intensive works in those areas in the meantime.

from todoman.

I think it's a bad idea to expose SQL queries.

from todoman.

I had to dump all this, since I'd not considered recurring events. The rewrite will have to take this into consideration.

from todoman.

We now have two caches:

• A JSON object that maps ids to filenames
• A pickled dict that caches all .ics files

Can we close this issue?

from todoman.

The idea behind this is to cache all these fields in a small sqlite db, and simply use SQL to filter (not exposing this to the user, of course). This makes the code on #68 a lot friendlier.

Since we only use these fields in list(), we don't even need to read files themselves (except out-of-date cache) except when edition/viewing a single todo.

Also, it means that we can keep ids valid for much longer times (since we can persist them there too). I'd eventually re-compute them on flush().

Edit: I've actually some work done on this, but since it's not 100%, it's mostly broken. :(

from todoman.

Persisting IDs may be a bit annoying because those will eventually become larger, and therefore be harder to type.

from todoman.