Underway should manage migrations in its own schema #11
Comments
Closed
maxcountryman
added a commit
that referenced
this issue
Oct 31, 2024
This is something of a hack to work around the fact that SQLx migrations do not currently support specifying a schema under which the migrations table will live. Here we provide a search path throughout our migrations and in the transaction that will run the migrations to ensure that migrations are applied to `underway._sqlx_migrations`. Note that this assumes a `public._sqlx_migrations` exists. In the future we should be able to use `sqlx.toml` to address this more robustly. That's expected as part of the `0.9.0` release of SQLx. Please see: launchbadge/sqlx#3383 Closes #11
maxcountryman
added a commit
that referenced
this issue
Oct 31, 2024
This is something of a hack to work around the fact that SQLx migrations do not currently support specifying a schema under which the migrations table will live. Here we provide a search path throughout our migrations and in the transaction that will run the migrations to ensure that migrations are applied to `underway._sqlx_migrations`. Note that this assumes a `public._sqlx_migrations` exists. In the future we should be able to use `sqlx.toml` to address this more robustly. That's expected as part of the `0.9.0` release of SQLx. Please see: launchbadge/sqlx#3383 Closes #11
maxcountryman
added a commit
that referenced
this issue
Oct 31, 2024
This is something of a hack to work around the fact that SQLx migrations do not currently support specifying a schema under which the migrations table will live. Here we provide a search path throughout our migrations and in the transaction that will run the migrations to ensure that migrations are applied to `underway._sqlx_migrations`. Note that this assumes a `public._sqlx_migrations` exists. In the future we should be able to use `sqlx.toml` to address this more robustly. That's expected as part of the `0.9.0` release of SQLx. Please see: launchbadge/sqlx#3383 Closes #11
maxcountryman
added a commit
that referenced
this issue
Oct 31, 2024
This is something of a hack to work around the fact that SQLx migrations do not currently support specifying a schema under which the migrations table will live. Here we provide a search path throughout our migrations and in the transaction that will run the migrations to ensure that migrations are applied to `underway._sqlx_migrations`. Note that this assumes a `public._sqlx_migrations` exists. In the future we should be able to use `sqlx.toml` to address this more robustly. That's expected as part of the `0.9.0` release of SQLx. Please see: launchbadge/sqlx#3383 Closes #11
maxcountryman
added a commit
that referenced
this issue
Oct 31, 2024
This is something of a hack to work around the fact that SQLx migrations do not currently support specifying a schema under which the migrations table will live. Here we provide a search path throughout our migrations and in the transaction that will run the migrations to ensure that migrations are applied to `underway._sqlx_migrations`. Note that this assumes a `public._sqlx_migrations` exists. In the future we should be able to use `sqlx.toml` to address this more robustly. That's expected as part of the `0.9.0` release of SQLx. Please see: launchbadge/sqlx#3383 Closes #11
maxcountryman
added a commit
that referenced
this issue
Oct 31, 2024
This is something of a hack to work around the fact that SQLx migrations do not currently support specifying a schema under which the migrations table will live. Here we provide a search path throughout our migrations and in the transaction that will run the migrations to ensure that migrations are applied to `underway._sqlx_migrations`. Note that this assumes a `public._sqlx_migrations` exists. In the future we should be able to use `sqlx.toml` to address this more robustly. That's expected as part of the `0.9.0` release of SQLx. Please see: launchbadge/sqlx#3383 Closes #11
maxcountryman
added a commit
that referenced
this issue
Oct 31, 2024
This is something of a hack to work around the fact that SQLx migrations do not currently support specifying a schema under which the migrations table will live. Here we provide a search path throughout our migrations and in the transaction that will run the migrations to ensure that migrations are applied to `underway._sqlx_migrations`. Note that this assumes a `public._sqlx_migrations` exists. In the future we should be able to use `sqlx.toml` to address this more robustly. That's expected as part of the `0.9.0` release of SQLx. Please see: launchbadge/sqlx#3383 Closes #11
maxcountryman
added a commit
that referenced
this issue
Oct 31, 2024
This is something of a hack to work around the fact that SQLx migrations do not currently support specifying a schema under which the migrations table will live. Here we provide a search path throughout our migrations and in the transaction that will run the migrations to ensure that migrations are applied to `underway._sqlx_migrations`. Note that this assumes a `public._sqlx_migrations` exists. In the future we should be able to use `sqlx.toml` to address this more robustly. That's expected as part of the `0.9.0` release of SQLx. Please see: launchbadge/sqlx#3383 Closes #11
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This isn't really supported at the moment but launchbadge/sqlx#3383 promises to make this possible.
Until then, it's possible to combine migrator sets, although it's not clear how to unwind this later.
The text was updated successfully, but these errors were encountered: