It's still not as nice as what's built into Rails, in my opinion. I'd
prefer to have the migration files be written in Python (as opposed to
raw SQL), like Rails migration files are written in Ruby. This looks
like it's probably better than any other option available for Django
right now.

Have any of you used any migration tool in Django?

It was less code/effort than researching all the available ones out  
there as I knew what I wanted to accomplish.

Since doing this, haven't had enough "pain level" to look at some of  
the other solutions.

Unlike you, Trey, I prefer to write the migrations in SQL instead of  
Python for a couple of reasons.  The primary of these reasons is that  
not all migrations are simple DDL changes. Sometimes there is the need  
to fix or otherwise manipulate data well, and it just feels as if you  
get a lot more control when writing in a language that the database  
understands.

On Sep 3, 2008, at 2:16 PM, Trey Piepmeier wrote:

If you ever think you are going to move to MySql just use it from the
get-go.  You could be setting yourself up for some pain later on.

The migrations are written in Python, to a certain extent. Here's a
migration that adds an index to a table:

from dmigrations.mysql import migrations as m
import datetime
migration = m.AddIndex('sessions', 'session', 'expire_date')

AddIndex is a class that "knows" the SQL for adding an index.
AddColumn, DropColumn and DropIndex are others. I'm hoping that people
will write more migration classes for other common operations.

Note that table creation still uses a raw SQL migration rather than a
AddTable class. This was just the simplest thing to do when the
migration system was first written; I certainly wouldn't oppose
creating a more Pythonic abstraction, and doing so would not require
any changes to dmigrations as it exists now. The only contract it
expects is that a migration is an object with an up() and a down()
method.

Hope that clears things up a bit, and sorry for the group invasion!

Cheers,

Thanks for the input.  That makes sense.

So basically, there are parts that are already abstracted to Python,
but not all of it yet.  And as more abstractions are added, they will
be usable as-is with the API.

Thanks for your work on this and Django in general.  I hope this
thread didn't come off as too negative, I just like to wax
philosophical on the differences between the popular frameworks! :)

-Trey

On Sep 3, 3:24 pm, Simon Willison <si...@simonwillison.net> wrote: