samg / timetrap

Simple command line timetracker
http://rubygems.org/gems/timetrap
Other
1.48k stars 116 forks source link

keep track of timetrap release in database #97

Open zerobuzz opened 10 years ago

zerobuzz commented 10 years ago

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.

samg commented 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.