Document sqlmigrate in migrations topic guide
|Reported by:||Phillip Marshall||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
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.
Change History (6)
comment:4 Changed 2 years ago by
|Component:||Migrations → Documentation|
|Summary:||add migrate --dry-run and --verbose to show database changes in SQL → Document sqlmigrate in migrations topic guide|
|Triage Stage:||Unreviewed → Accepted|
|Type:||New feature → Cleanup/optimization|