There are many migrations that don't require a lot of thought - for example, if we add a column to a table definition, we probably want to have an "ALTER TABLE...ADD COLUMN" statement show up in our migration.

The difficulty lies in the automation of changes where the requirements aren't obvious. What happens when you add a unique constraint to a column whose data is not already unique? What happens when we split an existing table in two? Completely automating database migrations is not possible.

That said - we shouldn't have to hunt down and handwrite the ALTER TABLE statements for every new column; this is often just tedious. Many other common migration tasks require little serious thought; such tasks are ripe for automation. Any automation attempted, however, should not interfere with our ability to write scripts by hand if we so choose; our tool should ''not'' be centered around automation.


Automatically generating the code for this sort of task seems like a good solution:
 * It does not obstruct us from writing changes by hand; if we don't like the autogenerated code, delete it or don't generate it to begin with
 * We can easily add other migration tasks to the autogenerated code
 * We can see right away if the code is what we're expecting, or if it's wrong
 * If the generated code is wrong, it is easily modified; we can use parts of the generated code, rather than being required to use either 100% or 0%
 * Maintence, usually a problem with auto-generated code, is not an issue: old database migration scripts are not the subject of maintenance; the correct solution is usually a new migration script.


Implementation is a problem: finding the 'diff' of two databases to determine what columns to add is not trivial. Fortunately, there exist tools that claim to do this for us: [http://sqlfairy.sourceforge.net/ SQL::Translator] and [http://xml2ddl.berlios.de/ XML to DDL] both claim to have this capability. 

...

All that said, this is ''not'' something I'm going to attempt during the Summer of Code.
 * I'd have to rely tremendously on a tool I'm not at all familiar with
 * Creates a risk of the project itself relying too much on the automation, a Bad Thing
 * The project has a deadline and I have plenty else to do already
 * Lots of people with more experience than me say this would take more time than it's worth

It's something that might be considered for future work if this project is successful, though. 