Code

Changes between Version 3 and Version 4 of SchemaEvolutionDocumentation


Ignore:
Timestamp:
08/02/07 21:47:26 (7 years ago)
Author:
public@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SchemaEvolutionDocumentation

    v3 v4  
    368368Correct, 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. 
    369369 
     370''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.'' 
     371 
     372It does not matter how you get from v1 => v3, as long as you get there with minimum theoretical information loss.  The following: 
     373 
     374'''v1 => v2 => v3''' 
     375 1. // v1 t1:{A} 
     376 1. add_field(B); 
     377 1. add_field(C); 
     378 1. del_field(A); 
     379 1. rename_table(t1,t2); 
     380 1. // v2 t2{B,C} 
     381 1. add_field(A); 
     382 1. del_field(C); 
     383 1. // v3 t2:{A,B} 
     384 
     385is functionally equivalent to: 
     386 
     387'''v1 => v3''' 
     388 1. // v1 t1:{A} 
     389 1. add_field(B); 
     390 1. rename_table(t1,t2); 
     391 1. // v3 t2:{A,B} 
     392 
     393And 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. 
     394 
    370395== Future Work == 
    371396