diff options
author | Monty Taylor <mordred@inaugust.com> | 2013-07-11 16:24:50 -0400 |
---|---|---|
committer | Monty Taylor <mordred@inaugust.com> | 2013-07-11 16:54:46 -0400 |
commit | a71799ea2cbfa1354c786991a85b610753f5474c (patch) | |
tree | 11381f15bdd75736cef5cd50978fe9af9560cf7c /doc/source/historical/ProjectDesignDecisionsAutomation.trac | |
parent | 85fe71617f301e2163a97108aaa70de5bfb6b4a5 (diff) | |
download | sqalchemy-migrate-a71799ea2cbfa1354c786991a85b610753f5474c.tar.gz |
Updated to OpenStack Build stuff.
Diffstat (limited to 'doc/source/historical/ProjectDesignDecisionsAutomation.trac')
-rw-r--r-- | doc/source/historical/ProjectDesignDecisionsAutomation.trac | 26 |
1 files changed, 26 insertions, 0 deletions
diff --git a/doc/source/historical/ProjectDesignDecisionsAutomation.trac b/doc/source/historical/ProjectDesignDecisionsAutomation.trac new file mode 100644 index 0000000..2f1c8b7 --- /dev/null +++ b/doc/source/historical/ProjectDesignDecisionsAutomation.trac @@ -0,0 +1,26 @@ +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.
\ No newline at end of file |