feat!: Add AlterField Operation to Migration Generator#368
feat!: Add AlterField Operation to Migration Generator#368kumarUjjawal wants to merge 5 commits intocot-rs:masterfrom
AlterField Operation to Migration Generator#368Conversation
Codecov Report❌ Patch coverage is
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
@seqre any feedback for me? |
seqre
left a comment
There was a problem hiding this comment.
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?
|
Sure, Thank you! |
3dac2e1 to
76b9835
Compare
|
@seqre I added more tests can you check if they are what you are expecting and any feedbacks next steps. Thanks! |
1df5eb5 to
c97bc84
Compare
|
@m4tx the error doesn't seem to come from my PR, can you take a look? |
seqre
left a comment
There was a problem hiding this comment.
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.
cot-cli/src/migration_generator.rs
Outdated
| 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" | ||
| ), |
There was a problem hiding this comment.
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
3f80674 to
3d80f57
Compare
seqre
left a comment
There was a problem hiding this comment.
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!
| #[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 | ||
| ), | ||
| ); |
| 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?; | ||
| } |
There was a problem hiding this comment.
Could you please write some tests that cover this part?
| 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?; | ||
| } |
There was a problem hiding this comment.
Could you please write some tests that cover this part?
| 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 | ||
| } |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Could you please write the docs in similar fashion as other items above?
| } | ||
| } | ||
|
|
||
| // TODO: docs |
There was a problem hiding this comment.
Could you please write the docs in similar fashion as other items above?
AlterField Operation to Migration GeneratorAlterField Operation to Migration Generator
|
Sorry about the git issues, I had a dirty tree and I messed up merge. Thanks for cleaning this. |
Add
AlterFieldOperation to Migration GeneratorOverview
This PR introduces support for the
AlterFieldoperation in the migration generator.Related Issues
#205
Reviewer Notes