[djrobstep]

Hey, thanks for the response!

I've written a lot of code on top of SQLAlchemy over the years, big fan of your work.

These points are mostly philosophical differences, I appreciate that not everybody has the same perspective I do.

But to me, thinking of database changes in terms of current state/goal state and the differences between them, is more intuitive than as a sequence of versions.

By heavyweight, I mean the need to generate or modify a migration file and version each time a change is required. When I'm working on an app and playing around with table structures I find it much easier to be able to just type "sync" and have everything automatically match what's defined in my models or setup scripts or whatever, without generating a new numbered version each time I make a change.

You don't have to build your schemas through hand-written DDL. You can still build your schemas through Python structures or however you want, as long as you can generate a target with it to compare against.

[zzzeek]

yes I can definitely see Migra is more productive when switching around between schemas in development. But I'm not sure how I'd go about using this approach if i need to deploy a fixed series of schema migrations to a production server farm.