-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persist store in DB instead of JSON #60
Comments
More details Setting up the databaseBelow shows an example of the current state json file and the requirement it imposes on the table schemas
We would need a separate table for each structure. This requires setting up the database (
and rollback with
Embed migrationEnforce database to be updated with embedded migration runner
sqlx schemaUtilize query/mutation resolversCreate query and muatation resolvers to replace existing functions from PersistedState struct to keep the database updated. Query example
Insert example for when new local attestation or remote messages are found
Delete example for pruning old data
Swap out existing PersistedState functions with database resolvers |
Problem statement
In order to save the Radio's state between reruns, currently we persist the state in a JSON file. That does the job of seamlessly restarting the Radio, but as Radio traffic, features, message types, collected data, etc, increases we will need a more scaleable approach to data persistence.
Expectation proposal
We should adopt an approach, similar to the one in Listener Radio, which uses
sqlx
.By default, it could use
sqlite
and still keep all the data in a local file, but more advanced users should be able to provide a postgres endpoint and store the Radio's data there.Open questions
Should we still keep JSON as an option?
The text was updated successfully, but these errors were encountered: