feat: use flyway for db migrations #1965
Conversation
Deploying with
|
| Latest commit: |
922a592
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2e0b4fd0.nft-storage-1at.pages.dev |
|
Stray observations about flyway:
Either of those could be used to set the It doesn't seem to support automatic rollbacks, but in the paid version you can write "undo migrations" to reverse a versioned migration. |
Codecov Report
@@ Coverage Diff @@
## main #1965 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 5 5
Lines 1259 1259
=========================================
Hits 1259 1259 Continue to review full report at Codecov.
|
|
Flyway seems quite simple and a solution for us to consider. Would love to see, the alternative, how it would be if we execute scripts on a github action with a postgres script, almost like we do in cron jobs with manual trigger. |
|
I'm curious about the custom alternative also. There are some things we'd like to do (like staging backup / rollback) that would be hard to fit into the Flyway scheme of things. It feels like Flyway wants to "own" the whole migration process, but will let you hook into it if you pay them 💸 |
Hey everyone, as I was distracting myself from something else, I started looking into using Flyway for database migrations, using the node-flywaydb package to pull down and run the flyway cli.
This is related to #1692, but will need discussion before we can call the matter resolved. I just figured it would be easier to talk about if we had some code we could point to 😄
Anyway, here's what's going on in the PR. The
db/migrationsdirectory now has flyway-compatible migrations that set up the DB schema as it currently is inmain.It uses Flyway's placeholders to set the
DAG_CARGO_*constants when setting up the foreign data wrapper.It also makes the assumption that if
DAG_CARGO_HOSTand friends aren't in the environment, you want to use the testing dag-cargo config instead of the foreign data wrapper. To make that work, if the vars for the FDW aren't there it will set the placeholderDAG_CARGO_TEST_MODEtotrue, and the cargo-related migrations are wrapped inIFstatements to run the test mode SQL if that var is true, and the FDW setup otherwise.On reflection, that might be too much magic - maybe it's better to read
DAG_CARGO_TEST_MODEfrom the environment instead, and always set it in our dev and test setups.All the placeholder stuff is in
db/flyway-config.cjs.I haven't thought through integrating with CI yet, since I wanted to get feedback and make sure this is what we actually want, etc.