26 lines
2.4 KiB
Plaintext
26 lines
2.4 KiB
Plaintext
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. |