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 25453,makemigrations suggestion seems to go against best practices,Benjamin Wohlwend,nobody,"When creating a migration that makes a formerly nullable field non-nullable, `makemigrations` has these suggestions: {{{ You are trying to change the nullable field 'foo' on bar to non-nullable without a default; we can't do that (the database needs something to populate existing rows). Please select a fix: 1) Provide a one-off default now (will be set on all existing rows) 2) Ignore for now, and let me handle existing rows with NULL myself (e.g. adding a RunPython or RunSQL operation in the new migration file before the AlterField operation) 3) Quit, and let me add a default in models.py }}} The second option seems to suggest to add the `RunPython` operation in the same migration file as the `AlterField` operation, which is against best practices of splitting schema- and data-migrations. This seems to be somewhat related to #24630, which updated the documentation to show how to split up the migration (albeit for a slightly different use case). I'm not sure how the output from `makemigrations` could be worded better, but it could e.g. link to the updated docs.",Cleanup/optimization,closed,Migrations,1.8,Normal,fixed,,piquadrat@…,Ready for checkin,1,0,0,0,0,0