Changes between Version 3 and Version 4 of SchemaEvolutionDocumentation

Timestamp:

Aug 2, 2007, 11:47:26 PM (17 years ago)

Author:

public@…

Comment:

--

SchemaEvolutionDocumentation

@@ -368 +368 @@
 Correct, however I thought this to be a highly unlikely scenario, not warranting the extra notational complexity.  But just as we support strings and tuples, there is nothing to say we can't extend it to support say a mapping of historical names to date ranges, if the need arises.
 
+''The 'aka' approach is ambiguous for all but trivial use cases. It doesn't capture the idea that database changes occur in bulk, in sequence. For example, On Monday, I add two fields, remove 1 field, rename a table. That creates v2 of the database. On Tuesday, I bring back the deleted field, and remove one of the added fields, creating v3 of the database. This approach doesn't track which state a given database is in, and doesn't apply changes in blocks appropriate to versioned changes.''
+
+It does not matter how you get from v1 => v3, as long as you get there with minimum theoretical information loss.  The following:
+
+'''v1 => v2 => v3'''
+ 1. // v1 t1:{A}
+ 1. add_field(B);
+ 1. add_field(C);
+ 1. del_field(A);
+ 1. rename_table(t1,t2);
+ 1. // v2 t2{B,C}
+ 1. add_field(A);
+ 1. del_field(C);
+ 1. // v3 t2:{A,B}
+
+is functionally equivalent to:
+
+'''v1 => v3'''
+ 1. // v1 t1:{A}
+ 1. add_field(B);
+ 1. rename_table(t1,t2);
+ 1. // v3 t2:{A,B}
+
+And this can be supported completely through introspection + metadata about what tables and columns used to be called.  If you load v2 or v3, the available information can get you there from v1, and if you load v3, the available information can get you there from v1 or v2.
+
 == Future Work ==