Python task manager from scratch, part 33: Updating the persistence logic for tasks

Now that we've modified Task, we can modify the persistence layer so that the creation times are stored and retrieved properly.

It can be tempting to compute overdue and stale when we save and load tasks, persisting it as we go. This is among the most common and damaging mistakes I see in data-adjacent code. The fact that you think of something as a property of a Task (or whatever else), and not a computed value, does not mean that it needs to be persisted.

Optional: go read a bit about the uniform access principle. There is nuance and controversy here, but the UAP is great to have in your conceptual toolbox, if only as a check against conflating facts about what an interface ought to look like and facts about how persistence ought to work.

So, we dodged that bullet. One bullet we did not dodge is that of having to do a data migration: our old tasks are in a format that is incompatible with the new database. You can either learn how to do a literal SQL migration now, or you can do what I did and:

(i) Delete tasks.db (be careful, as this will literally delete all the data that's there); (ii) Fire up a Python interpreter; (iii) Use the sqlite3 module to connect to tasks.db; (iv) Execute the SQLiteTaskRepository.CREATE_SCHEMA command on that database (with connection.cursor().execute(CREATE_SCHEMA)).

Once you've verified that the Pytest tests pass and that you can create and manipulate commands with the Web interface, you're ready to proceed.

Here's the current commit in the veery/ repository.