id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 24363,Combine ALTER TABLE .. MODIFY statements for multiple columns into one statement.,slachinger,nobody,"If a migration modifies multiple columns of a table for each column/field an ALTER TABLE statement is executed. However most DBMS (all but sqlite?) support modification of several columns at once. For example, the consider this migration: {{{ #!div style=""font-size: 80%"" {{{#!python class Migration(migrations.Migration): dependencies = [ ('core', '0001_initial'), ] operations = [ migrations.AlterField( model_name='employee', name='salary', field=models.BigIntegerField(), preserve_default=True, ), migrations.AlterField( model_name='employee', name='academic_degrees', field=models.CharField(max_length=200), preserve_default=True, ), ] }}} }}} This currently results in two ALTER TABLE statments being executed: {{{ #!div style=""font-size: 80%"" {{{#!sql ALTER TABLE employee MODIFY COLUMN salary bigint; ALTER TABLE employee MODIFY COLUMN academic_degrees varchar(200); }}} }}} But this takes twice as long as using only one ALTER TABLE statement since the whole table is essentially recreated twice (at least in MySQL but IIRC it is the same in PG): {{{ #!div style=""font-size: 80%"" {{{#!sql ALTER TABLE employee MODIFY COLUMN salary bigint, MODIFY COLUMN academic_degrees varchar(200); }}} }}} This is particulary annoying because it essentially multiplies the time the migration runs by the number of modified fields and thus causes much longer downtimes of the service. NOTE: this is most likely related to #24203 which refers to adding columns instead of modifying.",New feature,new,Migrations,1.7,Normal,,Modify Field Column,simon.lachinger@… emorley@… Phil Krylov Adam Johnson elonzh,Someday/Maybe,0,0,0,0,0,0