Best practices for database migrations
James Laver
james.laver at gmail.com
Mon Nov 18 14:43:39 GMT 2013
On Mon, Nov 18, 2013 at 2:13 PM, Edmund von der Burg
<evdb at ecclestoad.co.uk> wrote:
> On 18 November 2013 02:01, Simon Wistow <simon at thegestalt.org> wrote:
>> Is there a current favourite for doing database migrations (i.e having a
>> programatic way for a database to upgraded to a new version by having a
>> series of sql commands run on it)?
> However the Python/Django crowd do have
> http://south.readthedocs.org/en/latest/about.html which is probably
> 90% of the solution for 99% of the likely scenarios. I suspect it is
> similar to the active record approach, and well worth a look by anyone
> proposing to create a database migration toolset, especially the easy
> rollback support.
South is mostly lovely, except when you have a MySQL database. I've
found in practice you need to squash migrations a lot to avoid
difficulties if you're working off MySQL (South helpfully warns that
it wouldn't be a problem if you got a real database).
The guy who wrote south has written the schema migrations stuff that's
now in core django in 1.7 and it seems to work very well. South is
quite hacky for reasons that will become obvious when you've used it
for a while.
Obvious downside here is that it requires you keep a copy of your
models in Python rather than SQL. There's also quite a lot you can't
do to your database in django's model system and muttley may want
that.
Oh, and I mistakenly trolled muttley early by linking to ragtime. I
was actually meaning drift, https://github.com/macourtney/drift , but
it looks like the joke about sexps came in quite by accident :)
James
More information about the london.pm
mailing list