pub struct Migrator<'a> { /* private fields */ }Expand description
Applies and rolls back migrations, tracking which have run.
Implementations§
Source§impl<'a> Migrator<'a>
impl<'a> Migrator<'a>
Sourcepub fn new(db: &'a Database, migrations: Vec<&'a dyn Migration>) -> Self
pub fn new(db: &'a Database, migrations: Vec<&'a dyn Migration>) -> Self
A migrator over any database, with any list of migrations.
Both halves are deliberate, and together they are how an application provisions a tenant from its own admin screen rather than from the CLI: create the database, then run into it only the migrations belonging to the modules that tenant enabled.
let tenant = Database::connect(url).await?;
let migrator = Migrator::new(&tenant, wanted);
migrator.prepare().await?;
let report = migrator.run().await?;
println!("{} migrations applied", report.applied.len());App::migrations(...) is boot-time wiring and rustlavel migrate
targets DATABASE_URL; neither can do this, which is why it is worth
saying that this can.
Sourcepub fn with_table(self, table: &str) -> Result<Self>
pub fn with_table(self, table: &str) -> Result<Self>
Record applied migrations in a different table.
pub fn table(&self) -> &str
Sourcepub async fn prepare(&self) -> Result<()>
pub async fn prepare(&self) -> Result<()>
Create the tracking table if it is not there yet.
The batch number is what makes migrate:rollback undo one deployment’s
worth of migrations rather than one migration.
Sourcepub async fn applied(&self) -> Result<Vec<String>>
pub async fn applied(&self) -> Result<Vec<String>>
Names already applied, in the order they ran.
Sourcepub async fn pending(&self) -> Result<Vec<&'a dyn Migration>>
pub async fn pending(&self) -> Result<Vec<&'a dyn Migration>>
Migrations that have not run yet.
Sourcepub async fn run(&self) -> Result<MigrationReport>
pub async fn run(&self) -> Result<MigrationReport>
Run every pending migration.
A migration is not wrapped in a transaction, which is also what Laravel does. Wrapping one here would be a lie: the migration’s DDL and the tracking insert are separate statements, a pooled connection is not guaranteed to be the same one twice, and MySQL commits implicitly before and after every DDL statement regardless — a CREATE TABLE cannot be rolled back there at all.
A migration that needs to be atomic should open a transaction itself
with db.begin().
Sourcepub async fn rollback(&self) -> Result<MigrationReport>
pub async fn rollback(&self) -> Result<MigrationReport>
Roll back the most recent batch.
Sourcepub async fn fresh(&self, environment: &str) -> Result<MigrationReport>
pub async fn fresh(&self, environment: &str) -> Result<MigrationReport>
Drop every table in the schema, then migrate from scratch.
Refuses to run in production: this is the command that would delete a live database, and a confirmation prompt is not available to a library.