SQLAlchemy-Migrate upgrade scripts in a transaction

Written by dazza on July 27, 2008 — 8 Comments

SQLAlchemy Migrate is a really good tool for managing database upgrades for SQLAlchemy centric projects. I've been using it for 6 months on New Metal Army and I haven't had a screwed website upgrade yet!

For those that don't know SQLAlchemy-migrate allows you to version control database changes and easily upgrade and downgrade a database. Basically you write a python script with two functions: upgrade and downgrade. You test the script against the database, commit it to the SQLAlchemy-migrate version repository (not to be confused with your source control mechanism). Finally you upgrade your development database.

When it the time comes to deploy the new application you simply ask sqlalchemy-migrate to upgrade your database to the current version. sqlalchemy-migrate reads the current version of your schema from the database (via a custom table it inserts) and proceeds to upgrade your schema by running each upgrade script in turn.

Often you want your upgrades and downgrades to run within a transaction. Not because you expect them to fail but because while writing them you don't wont to leave the database partially upgraded or downgraded if your script fails. To do this I wrote a transaction decorator. Here is a template for an upgrade script:

#!/usr/bin/env python
# encoding: utf-8
 
from datetime import datetime
from sqlalchemy import *
from migrate import *
from migrate.changeset import *
 
metadata = MetaData(migrate_engine)
 
def transaction(f, *args, **kwargs):
    def wrapper(*args, **kwargs):
        connection = migrate_engine.connect()
        transaction = connection.begin()
        try:
            result = f(*args, **kwargs)
            transaction.commit()
            return result
        except:
            transaction.rollback()
            raise
        finally:
            connection.close()
 
    wrapper.__name__ = f.__name__
    wrapper.__dict__ = f.__dict__
    wrapper.__doc__ = f.__doc__
    return wrapper
 
@transaction
def upgrade():
    pass
 
@transaction
def downgrade():
    pass

I fill in the upgrade and downgrade functions and I'm done

I include the decorator in every script as it's good practice to make your scripts as independent as possible. If you imported it from a module you may improve it in the future and inadvertently break your old downgrade scripts.

I hope this helps you version control your database schema and data.

8 Comments to “SQLAlchemy-Migrate upgrade scripts in a transaction”

You can follow all the replies to this entry through the comments feed.

Sacha Varma

July 28, 2008 at 9:55 am | Permalink

A couple of questions:

1. I can see that this would work when upgrading the database one revision at a time, but if sqlalchemy-migrate applies multiple updates in sequence, you’d probably want a transaction around the whole sequence? (i.e. I reckon sqlalchemy-migrate should do the rollback management)

2. How do you manage updates that involve not just database changes, but also template & code changes? Is there a ‘turbogears-migrate’ that incorporates sqlalchemy-migrate?
dazza

July 28, 2008 at 10:13 am | Permalink

@Sacha Varma: your correct, there is no overall upgrade wrapper. Indeed it would be nice if all this was covered by the sqlalchemy-migrate. There has been some chatter on the sqlalchemy-migrate group about this. This is just a small step toward a bigger goal.

To manage code and database changes I version control the migrate repository in svn. So I can be sure that the code I update checkout syncs with upgrade scripts I am about to run.
Sacha Varma

July 28, 2008 at 10:21 am | Permalink

If you have an old model.py (A) and a new model.py (B), do you have to write the code to upgrade from A to B, or is there a tool that “diffs” the two and spits out the code to do the upgrade/downgrade?
dazza

July 28, 2008 at 10:42 am | Permalink

@Sacha Varma: there is a new command added in the latest version which creates a script from a diff between the database and your ‘model’ make_update_script_for_model.

See the change list here http://code.google.com/p/sqlalchemy-migrate/wiki/ChangesSince0_4_4. I haven’t used this myself but I think it does what you want.
Sacha Varma

July 28, 2008 at 11:32 am | Permalink

Python nub questions:

#!/usr/bin/env python
# encoding: utf-8

/usr/bin/env? Why not just /usr/bin/python? Is this just a way of not having to explicitly specify the location of python, and have it pick it up from your $PATH?

The encoding line presumably relates to the source code that follows?
dazza

July 28, 2008 at 12:46 pm | Permalink

@sacha: you are correct, by using env to launch python it will pick it up from the environment that the script is running in. It is just to stop a hard coded paths in the script. It’s not actually needed for this particular script since it is being invoked by an already running python interpreter but it’s part of my ‘new python template’ in TextMate.

The encoding is to follow PEP 263 http://www.python.org/dev/peps/pep-0263/ It just makes sure all unicode literals embedded in the code are in UTF8. Everything I do is in UTF8 so it stops non UTF8 string slipping in to the code base and causing interesting and sometimes difficult to track down bugs.
px

February 16, 2010 at 12:37 pm | Permalink

Is it working? I see that SQLalchemy-migrate works with autocommit after each operation. But if upgrade fails dwongrade is called. Maybe there have to be some extra configuration of sqlalchemy-migrate that I don’t know.
dazza

February 16, 2010 at 1:25 pm | Permalink

I should have updated this post, sorry I forgot, this doesn’t work with new versions of SQLAlchemy. I’m not sure why, I’m not currently using SQLAlchemy.

SQLAlchemy-Migrate upgrade scripts in a transaction

8 Comments to “SQLAlchemy-Migrate upgrade scripts in a transaction”

Leave a Reply

Project Euler Status

Categories

Recent Comments

Blogroll

Bosh Links

Meta