I've looked into doing this myself and brought it up a while ago (do a google groups search).
IMHO, the best way to achieve it is to take stock from RoR migrations. Trying to automate this process is fraught with caveats and gotchas and just isn't worth it. The RoR solution is to provide a migration class with upgrade() and downgrade() methods. In this scheme you have source files names 001_MyTable, 002_MyTable, 003_MyTable etc and each file has a class that implements upgrade and downgrade respectively. The database has a table that stores the versions of each table under the scheme. It's simple, easy to understand, leaves the important stuff for you to tailor and, most importantly to any objectors - It Just Works. There's nothing particularly Rubyish about it either (before Pythonic purists start arm waving :-) ) - it's an incredibly simple concept. What you need within the upgrade() and downgrade() methods are the abilities to create/drop tables, indexes and so on. Last time I looked SQLObject lacked the necessary functionality but I think SQLAlchemy fared slightly better. I had a few email exchanges with Ian Bicking (SQLObject) with regards to adding these base features into SQLAPI which I think is where they belong. Ideally for an ORM there'd be a low level of abstraction onto a db that allowed for features such as creating/dropping tables/ indices/columns etc. To my mind it'd make building the rest of an ORM on top of these base features much easier. The ORM layer would focus on linking these low level manipulation abilities to Python classes and their attributes. The ability to upgrade to new table definitions is a serious #1 feature for real world deployments. It's a shame, and curious to boot, that the talented devs behind SQLObject and SQLAlchemy don't have it on their radar and rely instead on users to hack about with manual table dumps etc. Adding core abstracted table manipulation abilities to one of the existing ORM's would make it possible and even relatively straight- forward. Justin On 3 May 2006, at 20:07, Evan Rosson wrote: > > Hey all, > > I'd like to create a tool to help with SQLAlchemy schema migration a > bit. I've been interested in this for a while now (ie. I'm not just > blindly copying a suggestion from this mailing list) - I'm working > on a > TG project which I know will have a good number of database changes > later on (lots of small changes, mostly), and I need a way to manage > that. SQLAlchemy fits many other requirements for my project, but > lacks > a tool to manage schema changes; I've been looking into how I'd make a > good schema migration tool - seems like a good candidate for my SoC > project. > > I've made good progress on my proposal, though it's not done just yet. > I think I've got a pretty good plan so far, but more info on how this > has been done before would be helpful. So, my question: has anyone out > there have a schema migration tool they've used and really liked? > > I'm familiar with these: > - SQLObject's versioning: > http://sqlobject.org/sqlobject-admin.html#versioning-upgrading > - Rails' migration: > http://api.rubyonrails.com/classes/ActiveRecord/Migration.html > - Writing migration scripts by hand (the "default" way to do things, > with no tool) > Anyone out there used something good for this that I haven't looked > into? > > Thanks. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
