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 23263,Document sqlmigrate in migrations topic guide,Phillip Marshall,nobody,"makemigrations has --dry-run and --verbosity 3, but that's for seeing what migrations will be generated, not the SQL itself. According to Andrew in this south ticket, it may be a harder question than it appears at first glance, because the actual SQL isn't known until it can ask the database a few things, and showing SQL for multiple changes would be a big mess too: http://south.aeracode.org/ticket/480 Being able to inspect the SQL to be run is a crucial feature for a migration tool. Fooling around with 1.7rc2's migrations so far, I've run a few initial migrations on a test database that have changed columns in ways that were never told to me. Undoing those migrations *dropped the tables*, and I didn't know about it until my applications started complaining. I admit, these unexpected changes are mostly likely due to how my models weren't 100% accurate to the tables created outside of django by legacy software. I don't blame django for them. For now though, I'm uncomfortable running any migrations without knowing exactly what they're going to do. This feature probably isn't needed by people running apps that are and always have been 100% django. But as someone in the trenches dealing with messy data structures from decades ago, I need a tool that will help me manage my data structures, not one that will obscure them from me. So for now, I'll stick to diffing between sqlall outputs, as tedious as it is. Thanks.",Cleanup/optimization,closed,Documentation,dev,Normal,fixed,,,Accepted,0,0,0,0,1,0