-
Notifications
You must be signed in to change notification settings - Fork 8
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
feat: db migrations #533
feat: db migrations #533
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main question is about whether we should outsource the db migrations code to the another crate, but in general this seems fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
Added #537 to revisit this pre-launch, and added a TODO comment in |
Description
Introduces db-migration functionality for the signer binary.
Note 1: I did first try using
sqlx
's migration functionality, but it pulls in dependencies which conflict with stacks-core deps. This seems to be documented as a known Cargo issue here. But in any case, handling them manually gives us a few more options, especially re: printing out pending migrations via a command line command.Note 2: I took the db-migrations "as-is" for now. When in a user environment we may want to re-think the two scripts for creating the schema and user as depending on a company's policies these operations may not be allowed.
Question on Note 2: Is there any particular reason why we felt we needed to use a separate schema from
public
? I'm going under the assumption that we should require that the sBTC signer has its own dedicated database and in the case of using pgsql the user will probably create their own user and give it appropriate permissions (as designated by us). I otherwise have a hard time envisioning that the signer will grow to a size where schema isolation is desired/required?Partially Closes: #532 (printing out pending db migrations is not in this PR)
Changes
include_dir
(which is similar toinclude_bytes
etc. but for entire directories) which compiles the database migrations into the signer binary.--migrate-db
which if set will attempt to apply any pending database migrations on signer startup. Default is false.new_test_database()
is updated with a flag for whether or not migrations should be applied. I had this originally for writing integration tests for the migrations themselves, but then decided that the migrations are implicitly tested for any test using this function so it wasn't explicitly needed. I left this flag in as it can be good for adding some negative integration tests (i.e. for when a user isn't using auto-migrations and has forgotten to apply migrations manually, etc.).PgStore
creates a new tablepublic.__sbtc_migrations
(I am assuming here that sBTC will have its own, dedicated db and that we can freely usepublic
) for keeping track of applied migrations.flyway
service entry indocker-compose.test.yml
to not run automatically in favor of db migrations being applied by code. If you use this compose file for local testing then you can still run it, justup flyway
manually.integration-test-full
target todown
the test env first (I ran into some issues here when it was lingering).Testing Information
Checklist: