cargo run -- up can not update the table field

[ryzn0518]

Description

In poem_example，update the table field in entity posts, add two fields, and then add two fields in

migration/ m20220120_000001_create_post_table

 .col(ColumnDef::new(Posts::Password).string().not_null())
.col(ColumnDef::new(Posts::Username).string().not_null())

#[derive(Iden)]
enum Posts {
    Table,
    Id,
    Title,
    Text,
    Password,
    Username
}

then execute migration/main.rs,

and the execution result is

and find that the fields in the database posts table are not updated.

why

1. update the fields and migration show Applying 1 pending migrations ,but the result is No pending migrations

[ctfdavis]

That's the expected behaviour according to the source code:

async fn up(db: &DbConn, mut steps: Option<u32>) -> Result<(), DbErr> {
    Self::install(db).await?;
    let manager = SchemaManager::new(db);

    if let Some(steps) = steps {
        info!("Applying {} pending migrations", steps);
    } else {
        info!("Applying all pending migrations");
    }

    let migrations = Self::get_pending_migrations(db).await?.into_iter();
    if migrations.len() == 0 {
        info!("No pending migrations");
    }
    // skipped
 }

The cli first checks the steps option and displays a message immediately. After that, it checks the database to know how many migrations are pending and then displays another message.

Therefore, in your attempt there is no pending migration. To add a new migration, you should generate a new migration as documented here. Alternatively, if you just want to edit the already migrated file, you can first roll it back before running it again. Hope this helps.

[billy1624]

Hey @diaojunxian, welcome! Sorry for the delay. I'm pretty sure the migration m20220120_000001_create_post_table has already been applied. That's why you alter the migration script of it and execute cargo run -- up do nothing for you. Because the migration you just edit has been applied and it won't apply it again.

You have two options:

1. Rollback the migration then re-apply it: execute cargo run -- down then carg run -- up
2. Create a new migration with scripts to add those two columns to the table

[billy1624]

Thanks!! @ctfdavis

[billy1624]

This might be related

• https://github.com/SeaQL/sea-orm/issues/1007

[billy1624]

Hey @diaojunxian, as a temporary workaround: execute cargo run on your migration crate. It will apply all pending migration at once.

[ryzn0518]

https://github.com/SeaQL/sea-orm/issues/989#issuecomment-1233718196

Hi @billy1624 , Thanks a lot for your answer. I have figured out what the current principle.

I describe my desired scenario.

when had created a data table, the service also inserted some data normally. At this time, when want to update the data table fields, for example, append two fields.

then, it is not feasible for me to add it to the original m20220120_000001_create_post_table. And need to create a new m20220120_000002_create_post_table, and then execute cargo run, which seems strange for code management.

[billy1624]

It's not desire to alter the old (applied) migration. You should always create a new migration if you want to alter the schema.

However, if you insist to change the old (applied) migration. You can rollback the migration then re-apply it by first executing cargo run -- down then carg run -- up or simply carg run.