Open zerobuzz opened 10 years ago
I've considered version of this idea, but never implemented it for fear I'd be over engineering. So far there has never been a breaking schema change, but perhaps timetrap has crossed the threshold where this kind of compatibility layer makes sense. Issue #96 is a great example of where this kind of tracking could come in handy.
for being able to changing the database format in the future, it would be cool to have a table that keeps track of the database schema version and the timetrap release. i propose:
create table 'version' ('timetrap' integer, 'schema' integer);
it's not a big deal that it has not been put in there from the start: should a schema change become necessary, timetrap can simply assume schema version 'old' on all databases that do not keep track.
i propose to do it now anyway because:
1) schema version: current time trap code could constrain the newest schema version now, so if in the future somebody would run an old timetrap executable on a new database by accident, there would be a (better) error. 2) timetrap release: interesting in case bugs become known that affect the consistency of the database.