Automatically applying migrations to a Django application's schema
MikeH
I'm currently preparing my team to use Django as our primary framework
and as part of this we need a way to keep our databases in sync.
>From the Django FAQ:
> you'll have to execute the ALTER TABLE statements manually in your database.
> That's the way we've always done it, because dealing with data is a very sensitive
> operation that we've wanted to avoid automating. That said, there's some work
> being done to add partially automated database-upgrade functionality.
I agree completely with this, and our developers write sql scripts to
migrate the database to the new structure, test the migration and
commit it so that everyone else can bring their schema up to date. The
problem is keeping track of what has been run on where and remembering
to run the right sql so that your application doesnt crash with an
OperationalError. We needed the process to be as easy to run and as
automated as syncdb.
We looked at the schema-migration branches but they dont seem to be as
current or complete as we need.
So I wrote a very simple schema migration tool which you can find at
http://www.aswmc.com/dbmigration/
It simply automates the application of migrations, written in SQL
(allowing you to supply a default bt of sql or an engine specific
version) or as Python functions, and keeps track of the ones that have
been applied to the schema so they don't get run again.
There is a patch to integrate it into syncdb, so now the stage of our
rollout that updates the database is as simple as running syncdb! I
posted the package to the django-users list and have had positive
feedback from various users there.
I'd really like to see something like this supplied with django so
that we don't have to resort to external scripts or bits of other
frameworks to automate our schema migrations.
Cheers,
Mike H
John Calixto
Interesting solution. So, to handle the "keeping track of what [schema
alteration] has been run on where" use case, developers would just edit
migration_list before running the migrations? I'm trying to get an idea
of how I would use this with my team.
I presume, if developer A had already applied the first couple
migrations to their testdb, they'd do something like:
migration_list = [
# 'migration1',
# 'migration2',
'migration3',
'migration4',
]
before running it. Is that how you use it?
John
Jeremy Dunck
...>
> I presume, if developer A had already applied the first couple
> migrations to their testdb, they'd do something like:
>
> migration_list = [
> # 'migration1',
> # 'migration2',
> 'migration3',
> 'migration4',
> ]
>
No, the migration contrib app has a model whose records consist of all
the migrations already run. Have a look at
contrib.dbmigration.migration.migration_has_run()