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
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:
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
(iv) Execute the
SQLiteTaskRepository.CREATE_SCHEMA command on that database (with
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.
Next post: Python task manager from scratch, part 34: Adding styles based on task states