Skip to content

feat!: Add AlterField Operation to Migration Generator#368

Open
kumarUjjawal wants to merge 5 commits intocot-rs:masterfrom
kumarUjjawal:alter-field
Open

feat!: Add AlterField Operation to Migration Generator#368
kumarUjjawal wants to merge 5 commits intocot-rs:masterfrom
kumarUjjawal:alter-field

Conversation

@kumarUjjawal
Copy link
Contributor

Add AlterField Operation to Migration Generator

Overview

This PR introduces support for the AlterField operation in the migration generator.

Related Issues

#205

Reviewer Notes

@github-actions github-actions bot added C-cli Crate: cot-cli (issues and Pull Requests related to Cot CLI) C-lib Crate: cot (main library crate) labels Jul 4, 2025
@codecov
Copy link

codecov bot commented Jul 4, 2025

Codecov Report

❌ Patch coverage is 72.72727% with 63 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
cot/src/db/migrations.rs 0.00% 42 Missing ⚠️
cot-cli/src/migration_generator.rs 88.88% 21 Missing ⚠️
Flag Coverage Δ
rust 89.54% <72.72%> (-0.12%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
cot-cli/src/migration_generator.rs 88.81% <88.88%> (+1.13%) ⬆️
cot/src/db/migrations.rs 78.17% <0.00%> (-4.66%) ⬇️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@kumarUjjawal
Copy link
Contributor Author

@seqre any feedback for me?

Copy link
Member

@seqre seqre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This operation has many edge cases, and it should be thoroughly tested. Can you please add more tests first?

Think about possible cases, such as: name change (this one can be skipped for now, it's tricky), type change, attributes change, etc. All those should be either handled or visibly err when a given case is unhandled or ambiguous.

It seems that cot-cli/src/migration_generator.rs does not have a test for alter model, would you be so kind and add that too?

@kumarUjjawal
Copy link
Contributor Author

Sure, Thank you!

@kumarUjjawal
Copy link
Contributor Author

@seqre I added more tests can you check if they are what you are expecting and any feedbacks next steps. Thanks!

@kumarUjjawal
Copy link
Contributor Author

@m4tx the error doesn't seem to come from my PR, can you take a look?

Copy link
Member

@seqre seqre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your patience. I fixed the PR so it compiles and the tests pass! I left two comments and I'll try to test it myself tonight.

Comment on lines 1128 to 1143
DynOperation::AddField { .. } => unreachable!(
"AddField operation shouldn't be a dependency of CreateModel \
because it doesn't create a new model"
),
DynOperation::RemoveField { .. } => unreachable!(
"RemoveField operation shouldn't be a dependency of CreateModel \
because it doesn't create a new model"
),
DynOperation::RemoveModel { .. } => unreachable!(
"RemoveModel operation shouldn't be a dependency of CreateModel \
because it doesn't create a new model"
),
DynOperation::AlterField { .. } => unreachable!(
"AlterField operation shouldn't be a dependency of CreateModel \
because it doesn't create a new model"
),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should just make a blanket default response, DynOperation will grow over time and it'd be annoying to add more entries to such match statements. The same would apply for lines 1174-1184. What do you think @m4tx?

Or should we just redo DynOperation so that all of those actions are just trait methods that we just call here? lol

Copy link
Member

@seqre seqre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @kumarUjjawal, it seems you force-pushed your old changes which broke tests and removed the custom operations added recently to master. I've fixed those for you, please remember to git pull before doing any changes!

Regarding the PR, we're getting closer with every iteration! This feature is really important, but it's slightly complicated, that's why I'm pushing for it to be well tested. I appreciate your efforts!

Comment on lines -837 to 844
#[expect(unreachable_code)]
print_status_msg(
StatusType::Modified,
&format!(
"Field '{}' from Model '{}'",
&migration_field.name, migration_model.model.name
&migration_field.name, app_model.model.name
),
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please bring this back

Comment on lines +529 to +539
OperationInner::AlterField {
table_name,
old_field: _,
new_field,
} => {
let query = sea_query::Table::alter()
.table(*table_name)
.modify_column(new_field.as_column_def(database))
.to_owned();
database.execute_schema(query).await?;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please write some tests that cover this part?

Comment on lines +613 to +624
OperationInner::AlterField {
table_name,
old_field,
new_field: _,
} => {
// To reverse an alteration, set the column back to the old definition
let query = sea_query::Table::alter()
.table(*table_name)
.modify_column(old_field.as_column_def(database))
.to_owned();
database.execute_schema(query).await?;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please write some tests that cover this part?

Comment on lines +1257 to +1268
DynOperation::AlterField {
new_field,
model_ty,
..
} => {
let mut ops = vec![(i, model_ty.clone())];
// Only depend on the new foreign key, not the old one
if let Some(to_type) = foreign_key_for_field(new_field) {
ops.push((i, to_type));
}
ops
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please write some tests that cover this part?

This one interests me, from what I've read this would only apply when changing constraint on the foreign key, but that's a 3-operation situation (remove constraint, modify, add constraint), which I'm not sure would be supported in our current setup.

RemoveModelBuilder::new()
}

// TODO: docs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please write the docs in similar fashion as other items above?

}
}

// TODO: docs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please write the docs in similar fashion as other items above?

@seqre seqre changed the title feat: Add AlterField Operation to Migration Generator feat!: Add AlterField Operation to Migration Generator Feb 16, 2026
@kumarUjjawal
Copy link
Contributor Author

Sorry about the git issues, I had a dirty tree and I messed up merge. Thanks for cleaning this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

C-cli Crate: cot-cli (issues and Pull Requests related to Cot CLI) C-lib Crate: cot (main library crate)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants