Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo run -- up can not update the table field #989

Closed
ryzn0518 opened this issue Aug 25, 2022 · 7 comments · Fixed by #1010
Closed

cargo run -- up can not update the table field #989

ryzn0518 opened this issue Aug 25, 2022 · 7 comments · Fixed by #1010
Assignees

Comments

@ryzn0518
Copy link

ryzn0518 commented Aug 25, 2022

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

image

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
@ryzn0518 ryzn0518 changed the title cargo run -- up can not update cargo run -- up can not update the table field Aug 25, 2022
@ctfdavis
Copy link

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
Copy link
Member

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
Copy link
Member

Thanks!! @ctfdavis

@billy1624
Copy link
Member

This might be related

@billy1624 billy1624 moved this to Triage in SeaQL Dev Tracker Sep 1, 2022
@billy1624 billy1624 moved this from Triage to In Progress in SeaQL Dev Tracker Sep 1, 2022
@billy1624 billy1624 self-assigned this Sep 1, 2022
@billy1624
Copy link
Member

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

@ryzn0518
Copy link
Author

ryzn0518 commented Sep 2, 2022

#989 (comment)

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
Copy link
Member

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.

@billy1624 billy1624 moved this from Review to Done in SeaQL Dev Tracker Nov 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants