You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When running migrations from Rust code, the only way (as far as I know) is passing the path to the migrations directory. After this, it is not possible to touch the migrations contents. This makes it impossible to parameterize the migrations. E.g. if a migration needs to be run for multiple schemas.
Describe the solution you'd like
Two complementary solutions could be applied.
The first (easier) step would be modifying the Migrator trait to allow for manual insertion of migrations via string. This way, migration contents would be pushed by the application with arbitrary content. This would solve the problem because the substitution step would be done by the application before passing the migration contents to Migrator.
The second (more complex) step would be to implement in sqlx a variable substitution feature for migrations. So that the application can register the variables and their replacement to the Migrator, which can continue to work with a Path, given that it will take care of variable substitution.
The two solutions could then live side by side for maximum flexibility.
Describe alternatives you've considered
I am trying to work around the problem by manually replacing the content of the migrations field of the Migrator struct, but that does not look like a very clean solution.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When running migrations from Rust code, the only way (as far as I know) is passing the path to the migrations directory. After this, it is not possible to touch the migrations contents. This makes it impossible to parameterize the migrations. E.g. if a migration needs to be run for multiple schemas.
Describe the solution you'd like
Two complementary solutions could be applied.
The first (easier) step would be modifying the
Migrator
trait to allow for manual insertion of migrations via string. This way, migration contents would be pushed by the application with arbitrary content. This would solve the problem because the substitution step would be done by the application before passing the migration contents toMigrator
.The second (more complex) step would be to implement in sqlx a variable substitution feature for migrations. So that the application can register the variables and their replacement to the
Migrator
, which can continue to work with aPath
, given that it will take care of variable substitution.The two solutions could then live side by side for maximum flexibility.
Describe alternatives you've considered
I am trying to work around the problem by manually replacing the content of the
migrations
field of theMigrator
struct, but that does not look like a very clean solution.The text was updated successfully, but these errors were encountered: