Implement an SQLite cache

[WhyNotHugo]

Use a cache for:

• Faster startup times
• Keeping a proper index of ids to show
• Simplify filtering/sorting by merely using SQL

[WhyNotHugo]

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.

[untitaker]

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

[WhyNotHugo]

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.

[WhyNotHugo]

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

[untitaker]

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?

[WhyNotHugo]

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. :(

[untitaker]

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