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