Reading https://riverqueue.com/docs/migrations I'm struck by the fact that it may be hard (over time) to figure out if the version of the schema I'm running in my database matches the schema expected by the version river that I've got in my go.mod / go.sum.
I also think having river validate would make it much easier for teams like mine to integrate this into our existing migrations workflow. I.e. we could run river validate in CI and during development and detect if our existing migrations sequence needs to be updated.
(I don't think it'd be the end of the world to add river migrate-up during deploy right next to our migrate up command. However, having the two work together during development is preferable to having two "migrations managers" running during our deploys.)
Reading https://riverqueue.com/docs/migrations I'm struck by the fact that it may be hard (over time) to figure out if the version of the schema I'm running in my database matches the schema expected by the version
riverthat I've got in mygo.mod/go.sum.I also think having
river validatewould make it much easier for teams like mine to integrate this into our existing migrations workflow. I.e. we could runriver validatein CI and during development and detect if our existing migrations sequence needs to be updated.(I don't think it'd be the end of the world to add
river migrate-upduring deploy right next to ourmigrate upcommand. However, having the two work together during development is preferable to having two "migrations managers" running during our deploys.)