easier data update path?

[fgregg]

if i read everything correctly, the postgres database is completely determined by the input data files.

if so, perhaps this data flow could work:

1. build the database locally or on github actions
2. dump the database and store it on an s3 bucket
3. on deploy, pull the database dump from the s3 bucket and restore the database (overwriting the existing tables)

could that work @hancush ?

[hancush]

It could, especially if you can check whether the dump has been updated before restoring so the data isn't needlessly updated during deployment.

GitHub Actions makes most sense to me. You could build and upload a fresh dump between the testing and deployment steps when we merge into master. Then the staging DB would be refreshed during deployment, and we'd simply need to trigger a prod deployment (no need to rebuild the database again) to deploy the new data.

[fgregg]

okay, so the Pension objects and Annual report are not derived from the data. They are currently created in the admin interface.

So, the flow would need to be

1. Get the most recent database dump
2. Create any new Pension or Annual report objects needed
3. Build the database github actions
4. And so on.