Best practices for embedding migrations #3565
Unanswered
maxcountryman
asked this question in
Q&A
Replies: 1 comment 3 replies
-
A goal of #3383 is to allow you to change the table that tracks migrations for an app, making it a lot easier to have multi-tenant databases. You would want your app to have a dedicated schema that it owns and put the migrations table in there. Currently, the schema would need to exist before the migrations run but I could add a Then you wouldn't need to merge the sets, the user would just run your migrations and then their own or vice versa. I plan to land that feature in 0.9.0 which I hope to get out in the next month or so. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi folks,
I'm looking for some guidance on the current best practice for shipping migrations from a library that's meant to work alongside other projects already using SQLx.
Currently the best I've come up with is to provide a
Migrator
as a static that users can then combine with their own migrations. Something like:While I think this technically works there's a couple of downsides:
Migrator
like this requires using semver-exempt fields for now.If there's a blessed path I'm overlooking I'd appreciate someone pointing it out! 🙂
Beta Was this translation helpful? Give feedback.
All reactions