Changes between Version 2 and Version 3 of SchemaEvolutionDocumentation


Ignore:
Timestamp:
07/31/07 12:35:41 (8 years ago)
Author:
public@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SchemaEvolutionDocumentation

    v2 v3  
    4848patching file db/backends/sqlite3/introspection.py
    4949patching file db/models/fields/__init__.py
    50 patching file db/models/options.py}}}
     50patching file db/models/options.py
    5151}}}
    5252
     
    366366''Unless I'm missing something, the aka approach doesn't track exactly which name versions correlate with other versions. Consider; your aka chain for one field could indicate a rename from 'foo' to 'bar' to 'foo' to 'bar'; a second field could indicate renames from 'whiz' to 'foo' to 'whiz', etc. A tuple of historical names doesn't tell me which sets of names were in use concurrently; so if I find a database with a field called 'foo' which requires migration, is 'foo' the first field or the second?''
    367367
    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 extend it to support say a mapping of historical names to date ranges, if the need arises.
     368Correct, 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
    370370== Future Work ==
Back to Top