Atomic migration

[billy1624]

PR Info

• Closes Atomic migrations #1378

New Features

• Executes "atomic" migrations on Postgres, that is migrations will be executed with a transaction when the target database is Postgres
• Starts a transaction and execute SQL inside migration up and down

use sea_orm_migration::prelude::*;
use sea_orm_migration::sea_orm::{entity::*, query::*};

#[derive(DeriveMigrationName)]
pub struct Migration;

#[async_trait::async_trait]
impl MigrationTrait for Migration {
    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
        let db = manager.get_connection();

        let transaction = db.begin().await?;

        cake::ActiveModel {
            name: Set("Cheesecake".to_owned()),
            ..Default::default()
        }
        .insert(&transaction)
        .await?;

        transaction.commit().await?;

        if std::env::var_os("ABOARD_MIGRATION").eq(&Some("YES".into())) {
            return Err(DbErr::Migration(
                "Aboard migration and rollback changes".into(),
            ));
        }

        Ok(())
    }

    async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {
        let db = manager.get_connection();

        let transaction = db.begin().await?;

        cake::Entity::delete_many()
            .filter(cake::Column::Name.eq("Cheesecake"))
            .exec(&transaction)
            .await?;

        transaction.commit().await?;

        Ok(())
    }
}

mod cake {
    use sea_orm_migration::sea_orm::entity::prelude::*;

    #[derive(Clone, Debug, PartialEq, Eq, DeriveEntityModel)]
    #[sea_orm(table_name = "cake")]
    pub struct Model {
        #[sea_orm(primary_key)]
        pub id: i32,
        pub name: String,
    }

    #[derive(Copy, Clone, Debug, EnumIter, DeriveRelation)]
    pub enum Relation {}

    impl ActiveModelBehavior for ActiveModel {}
}

Breaking Changes

• Changed the type of SchemaManager::conn to SchemaManagerConnection
• Changed the input type of SchemaManager::new() to IntoSchemaManagerConnection
• Changed the return type of SchemaManager::get_connection() to &SchemaManagerConnection<'c>
• Changed the connection parameter of MigratorTrait's methods
  • get_migration_models, get_migration_with_status, get_pending_migrations, get_applied_migrations, install and status methods take ConnectionTrait as the connection
  • fresh, refresh, reset, up and down methods take IntoSchemaManagerConnection as the connection

Changes

• Added SchemaManagerConnection and IntoSchemaManagerConnection

[tyt2y3]

Just to clear some questions in my mind, so the updated default behaviour will be: wrapping the entire up/down execution in a transaction, only if it's postgres?

[billy1624]

Just to clear some questions in my mind, so the updated default behaviour will be: wrapping the entire up/down execution in a transaction, only if it's postgres?

Hey @tyt2y3, the new behaviour is:

The fresh, refresh, reset, up and down methods now take a &DatabaseConnection or a &DatabaseTransaction.

Then, inside each method, it will start a transaction to execute the migrations only if it's a Postgres connection. For non-Postgres connection, it just use connection as-is and execute the migrations as usual.

[tyt2y3]

I suspect this should be abort ?

[billy1624]

Oppps, what a typo

[tyt2y3]

Why open a transaction here? Just want to confirm, the behaviour should be no different whether we open a transaction or not, right? Because it's already inside a transaction (on Postgres)?

[billy1624]

1. I want to show it's possible to open a transaction inside migrate up & down.

2. For Postgres, yes, it's no difference. Because as you said you're already inside a transaction. However, the story is different for MySQL and SQLite. Opening a transaction is vital because the migration itself isn't atomic. If you want to seed the database atomically then you need to start a transaction yourself.

[tyt2y3]

Got it, cool

[tyt2y3]

For any backend, aborting the migration BEFORE committing makes more sense?

[billy1624]

Sure! see if both transactions got rolled back at the same time

[billy1624]

face72b

[tyt2y3]

OK. I also have some adjustments to make