Feature/SQLite persistence

[JGsouzaa]

SQLite feature developed based on #11

*Development Summary:

---

[sqlite.rs file (NEW FILE)]:

Implemented the following functions:

• check_db
• _createdb
• _check_schema
• _fill_projects_table
• _check_initial_row
• store_run
• store_mutants
• check_mutation_folder
• get_files_from_folder
• get_file_diff
• get_hash_from_diff
• update_status_mutant
• update_command_to_test_mutant
• update_mutants_table

Implemented the following tests:

• test_db_creation_and_seed
• test_store_run_creates_row
• test_store_mutants_inserts_rows
• test_update_status_mutant
• test_update_command_mutant

---

[main.rs file (MODIFICATIONS)]:

Implemented the following logic:

• Added mod sqlite.rs
• Optional SQLite flag for mutation + handler
• Optional SQLite flag for analyze with --run_id + handler

---

[lib.rs file (MODIFICATIONS)]:

• sqlite.rs module

---

[git_changes.rs file (MODIFICATIONS)]:

• get_commit_hash function implementation

---

[error.rs file (MODIFICATIONS)]:

• Added Sqlite and MissingDbPath errors

---

[analyze.rs file (MODIFICATIONS)]:

• Adapted run_analysis signature to get db_path and run_id
• Added update_status_mutant and update_command_to_test_mutant on current logic
• Changed find_mutation_folders visibility to public so it can be called from the sqlite.rs module

---

[Cargo.toml file (MODIFICATIONS)]:

• Added rusqlite and sha2 dependencies

---

*Additional comments:

• strategy, config_json from the current execution config -> NOT IMPLEMENTED

• The database schema follows the issue documentation entirely, with only one exception on table mutant that was inserted an additional column called file_name to query on analyze section

• Apart from the code tests, the following functional tests were performed manually:

  • (mutate) -> --sqlite flag optional, normal behavior {OK}

  • (mutate --sqlite ) -> Creates/open "db/mutation.db" and uses it {OK}

  • (mutate --sqlite results.db) -> Creates/open "db/results.db" and uses it {OK}

  • (mutate --sqlite ...) -> Verify INSERT OR IGNORE INTO projects (name, repository_url) VALUES ('Bitcoin Core', 'https://github.com/bitcoin/bitcoin'); {OK}

  • (mutate --sqlite...) -> General behavior: Open DB (create if missing) Ensure projects seed (bitcoin core), create run, insert mutants {OK}

  • (analyze --sqlite) -> Asks for run_id {OK}

  • (analyze --sqlite <db_file> <run_id> ) -> Record standard commands {OK}

  • (analyze <without file (-f ...)> --sqlite <run_id> ...) -> Record only for run_id, behave like analyze normally {OK}

---

*Further implementations suggestion:

• Modify logic when grabbing file extensions (current supports only for .cpp, .h and .py files)
• Implement help options for flag --sqlite
• Insert one more table column on table runs indicating the total number of mutants generated
• Explore options for compress the data on column "diff" on table "mutants" if diffs become hard to store and read
• Implement a folder called bcore-mutation on the project that it's running to hold "db" and "mutants" folders apart from original project

[brunoerg]

Please, you should better organize your commits by squashing some of them.

[JGsouzaa]

Please, you should better organize your commits by squashing some of them.

Thanks for the suggestion. I’ve done the squash as recommended. If you have any further tips on how to better organize the commits, I’d be happy to hear them.

[brunoerg]

I think the approach went to a wrong direction. The idea of having sqlite persistence is not relaying on muts-* folder anymore. When generating the mutants and storing them, you don't need the muts-* folder, you could do it in the source code. Again, the idea is not having these folders anymore.

Also, some points we could take in consideration - here or in a follow-up:

1. The README says --run_id but the correct one is --runid.
2. Analysis should run only for the "pending" mutants. Imagine a scenario where the power went out right in the middle of the analysis, and you'd like to resume it. Therefore, you would need to run the analysis for the mutants that haven't been analyzed yet, not for all of them.
3. It would be great if we had a new command, something like "report" that would generate the .json file (the result as we have now) based on unkilled mutants from a specified run_id or (even better) from a date range.
4. Would be great to print the run id after running mutate. This way I know the run id to then run the analysis. Without it, I would have to check the database by myself.

[brunoerg]

Also, it needs rebase.

[brunoerg]

Closing in favor of #35.