Retire github mirror, repo moved to opendevHEADmaster

1 files changed, 0 insertions, 26 deletions

diff --git a/doc/source/historical/ProjectDesignDecisionsAutomation.trac b/doc/source/historical/ProjectDesignDecisionsAutomation.trac
deleted file mode 100644
index 64810d8..0000000
--- a/doc/source/historical/ProjectDesignDecisionsAutomation.trac
+++ /dev/null
@@ -1,26 +0,0 @@
-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