You still need a system for tracking which changes have been applied to your database and for distributing the changes to the rest of your team.

Even if you don't use South's automatic migration generation, its database-independent schema modification api [1], dependency tracking, and tracking of which migrations have been run, are useful and necessary. In fact, the automatic generation of migrations is an optional feature of South that was not in it when first released.

When you need to write SQL and interact with your database directly, using `db.execute` inside a South migration is a nice way to do it.

[1]: http://south.readthedocs.org/en/latest/databaseapi.html

that is not a viable practice over the long run. the entire point of using a migrations tool is so you can migrate the schema and the data forwards and backwards automatically and consistently every time. attempting to do that with raw SQL scripts is a disaster waiting to happen. its so bad that the entire idea of a migration tool was invented to solve this problem.

so I ask again: what's your alternative (given that avoiding raw SQL scripts is the problem you're trying to solve)?

I'm getting sucked into an argument I don't really care about because I actually like South and use it in production for some things.

But I mean idempotent SQL takes care of the vast majority of all this stuff you mentioned. Write your SQL properly and it doesn't matter whether or not it's been applied before.

I don't know about postgres offhand, but there aren't idempotent solutions to some DDL operations in mysql. (alter table add column, off the top of my head)

Yeah in Postgres you can check for the existence of a column in a table. If it exists/doesn't exist you can drop/add the column. Obviously "ALTER TABLE x ADD COLUMN y" isn't idempotent, but the whole SQL statement around it can be idempotent.

I've been on a project that was doing exactly this. It's a giant PITA and we found ourselves slowly implementing something that looks a lot like South in order to mitigate all the problems we encountered. So we dropped this approach entirely and just used South. With a half decent migration strategy it's so much more robust than messing around with SQL. Unless there are specific edge cases that a migration tool can't deal with, use one.