Changes between Version 2 and Version 3 of SchemaEvolutionDocumentation

Timestamp:

Jul 31, 2007, 12:35:41 PM (17 years ago)

Author:

public@…

Comment:

--

SchemaEvolutionDocumentation

@@ -48 +48 @@
 patching file db/backends/sqlite3/introspection.py
 patching file db/models/fields/__init__.py
-patching file db/models/options.py}}}
+patching file db/models/options.py
 }}}
 
@@ -366 +366 @@
 ''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?''
 
-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.
+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.
 
 == Future Work ==