Initialize or open an existing database.
Inspects a module for functions starting with upgradeV to create a table of functions that can be used to upgrade a database.
If the database start it version 0, not initialized, then initialize to the latest schema version.
2018-04-08
2018-11-25
2019-04-06
2019-08-28
2019-11-12
2020-01-12
2020-01-21
2018-04-22
2018-09-01
2018-09-24
2018-09-30
2018-10-11
2018-10-15
2018-10-20
2018-11-10
Track all test cases that has been found by the test suite output analyzer. Useful to find test cases that has never killed any mutant. name should match test_case_killed_v2_tbl TODO: name should be the primary key. on a conflict a counter should be updated.
checksum is 128bit. Using a integer to better represent and search for them in queries.
The lower 64bit of the checksum should be good enough as the primary key. By doing it this way it is easier to update a marked mutant without "peeking" in the database ("insert or update").
The defaults for the schema is the state that the state machine start in.
there shall never exist two mutations points for the same file+offset.
the status of a mutant. if it is killed or otherwise. multiple mutation operators can result in the same change of the source code. By coupling the mutant status to the checksum of the source code change it means that two mutations that have the same checksum will "cooperate". TODO: change the checksum to being NOT NULL in the future. Can't for now when migrating to schema version 5->6. time = ms spent on verifying the mutant timestamp = is when the status where last updated. Seconds at UTC+0. added_ts = when the mutant where added to the system. UTC+0. test_cnt = nr of times the mutant has been tested without being killed.
This could use an intermediate adapter table to normalise the test_case data but I chose not to do that because it makes it harder to add test cases and do a cleanup.