You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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.
timetrap release: interesting in case bugs become known that affect the consistency of the database.
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: