24 releases
0.8.14 | Apr 3, 2024 |
---|---|
0.8.13 | Mar 29, 2024 |
0.8.12 | Jan 22, 2024 |
0.8.11 | Sep 13, 2023 |
0.1.0 | Nov 22, 2015 |
#34 in Database interfaces
164,551 downloads per month
Used in 30 crates
(19 directly)
115KB
2.5K
SLoC
Refinery strives to make running migrations for different databases as easy as possible. It works by running your migrations on a provided database connection, either by embedding them on your Rust code, or via the refinery_cli.
Currently postgres
, tokio-postgres
, mysql
, mysql_async
, rusqlite
and tiberius
are supported.
If you are using a driver that is not yet supported, namely SQLx
you can run migrations providing a Config
instead of the connection type, as Config
impl's Migrate
. You will still need to provide the postgres
/mysql
/rusqlite
/tiberius
driver as a feature for Runner::run
and tokio-postgres
/mysql_async
for Runner::run_async
.
refinery
works best with Barrel
but you can also have your migrations in .sql
files or use any other Rust crate for schema generation.
Usage
- Add refinery to your Cargo.toml dependencies with the selected driver as feature eg:
refinery = { version = "0.8", features = ["rusqlite"]}
- Migrations can be defined in .sql files or Rust modules that must have a function called
migration
that returns aString
. - Migrations can be strictly versioned by prefixing the file with
V
or not strictly versioned by prefixing the file withU
. - Migrations, both .sql files and Rust modules must be named in the format
[U|V]{1}__{2}.sql
or[U|V]{1}__{2}.rs
, where{1}
represents the migration version and{2}
the name. - Migrations can be run either by embedding them in your Rust code with
embed_migrations
macro, or via refinery_cli.
Example: Library
use rusqlite::Connection;
mod embedded {
use refinery::embed_migrations;
embed_migrations!("./tests/sql_migrations");
}
fn main() {
let mut conn = Connection::open_in_memory().unwrap();
embedded::migrations::runner().run(&mut conn).unwrap();
}
For more library examples, refer to the examples
.
Example: CLI
NOTE:
- Contiguous (adjacent) migration version numbers are restricted to
u32
(unsigned, 32-bit integers). - Non-contiguous (not adjacent) migration version numbers are restricted to
u32
(unsigned, 32-bit integers).
export DATABASE_URL="postgres://postgres:secret@localhost:5432/your-db"
pushd migrations
# Runs ./src/V1__*.rs or ./src/V1__*.sql
refinery migrate -e DATABASE_URL -p ./src -t 1
popd
Example: Deadpool
let mut conn = pool.get().await?;
let client = conn.deref_mut().deref_mut();
let report = embedded::migrations::runner().run_async(client).await?;
Non-contiguous VS Contiguous migrations
Depending on how your project/team has been structured will define whether you want to use contiguous (adjacent) migrations V{1}__{2}.[sql|rs]
or non-contiguous (not adjacent) migrations U{1}__{2}.[sql|rs]
.
If migration sequential numbering reflects the order they were developed and, they are deployed in the order they are numbered, you won't run into any problems using contiguous migrations.
This is because you can be sure the next migration being run is always going to have a version number greater than the previous.
With non-contiguous migrations there is more flexibility in the order that the migrations can be created and deployed.
If developer 1 creates a PR with a migration today U11__update_cars_table.sql
, but it is reviewed for a week.
Meanwhile, developer 2 creates a PR with migration U12__create_model_tags.sql
that is much simpler and gets merged and deployed immediately.
This would stop developer 1's migration from ever running if you were using contiguous migrations because the next migration would need to be > 12.
Implementation details
refinery works by creating a table that keeps all the applied migrations' versions and their metadata. When you run the migrations Runner
, refinery compares the applied migrations with the ones to be applied, checking for divergent and missing and executing unapplied migrations.
By default, refinery runs each migration in a single transaction. Alternatively, you can also configure refinery to wrap the entire execution of all migrations in a single transaction by setting set_grouped to true.
Rollback
refinery's design was based on flyway and so, it shares its earlier philosophy on undo/rollback migrations. Flyway has since changed it's opinion but refinery hasn't. To undo/rollback a migration, you have to generate a new one and write specifically what you want to undo.
MSRV
refinery aims to support stable Rust, the previous Rust version, and nightly.
Async
Starting with version 0.2 refinery supports tokio-postgres, mysql_async
and Tiberius
For Rusqlite, the best way to run migrations in an async context is to run them inside tokio's spawn_blocking
for example.
Contributing
🎈 Thanks for your help to improve the project! No contribution is too small and all contributions are valued, feel free to open Issues and submit Pull Requests.
License
This project is licensed under the MIT license.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in refinery by you, shall be licensed as MIT, without any additional terms or conditions.
Dependencies
~5–21MB
~304K SLoC