Data Store: Cleanup/simplify the implementation #19
Labels
Comments
rtamalin
added a commit
that referenced
this issue
Jun 13, 2024
Leverage foreign key cascaded delete constraints to ensure that deletion of reports triggers a cascaded delete of associated bundles, triggering cascaded deletes of associated bundles. To support this we need to ensure that SQLite3 foreign_key processing is enabled when we open the SQLite3 based client data store. Similarly we want to enable Write Ahead Log (WAL) based journalling mode for our data store. These options will be automatically included in the SQLite3 data source specification if not already provided. Cleanup the TelemetryProcessor and associated TelemetryCommon interface definitions, leveraging variadic functions to eliminate multiple similar methods. Similarly for the DatabaseStorer interface. Update associated implementations to match revised interface definitions and remove any newly redundant methods. Implement helper functions that can be used to generate the SQL queries needed to populate the row structures of a table, or count the number of matching rows. Update test cases to ensure that deleting a report triggers appropriate cascaded deletes that remove associated bundles and items. Relates: #19 Closes: #20 #18
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current implementation of the Client Data Store has multiple implementation and interface levels owing to the original PoC investigations of possible implementations for it.
Now that we have settled on using an SQLite3 backend we can eliminate the unecessary levels of complexity.
We should define a
DataStorerinterface which defines the functional interfaces we require our Client Data Stores to provide, and an SQLiteDS implementation of that interface.The text was updated successfully, but these errors were encountered: