The SQLAlchemy migrate project has reawakened after a long slumber. And I couldn’t be happier. Evolutionary database development, or “migrations” as the Rails folks have re-labeled the process, is an important piece of the agile web development puzzle.
It’s possible to do without it but I can’t think of a single project I’ve worked on in the last couple of years that didn’t need something. I’ve helped to hack things together for various groups, and I’ve never been particularly satisfied with our one-off solutions. Particularly when everything I’ve worked on has had needed a robust, standardized system for mananging and versioning database schemas.
Today, thanks to Christian Simms and Jan Dittberner, SQLAlchemy Migrate now works with SQLAlchemy 0.4. Which means that I can now use in in almost every project I have. I expect that this will bring a new wave of users, and I know that it opens the door for a whole new set of features.
This is also a core feature that I think TurboGears 2 needs to have to really be complete web development toolkit, and now we’ve got it. I don’t want to sound like a broken drum here, but I’m very happy that this isn’t part of the TurboGears package. It’s better because it’s not part of the framework. Anybody who uses SQLAlchemy in GUI’s or in command line tools, or whatever can (and probably should) use these Migrate, and the likely wouldn’t want to install a web-framework just to manage their database schemas.
Question for the masses:
On another note, there’s one django project that is the only thing I’m currently working on that doesn’t use SQLAlchemy, and I must confess to being bewildered by the array of Django schema migration projects out there. So any of you Djangonaughts with advice, recommendations, tips on how to do schema evolution on that project would be very welcomed.