Code

Changes between Version 18 and Version 19 of SummerOfCode2011


Ignore:
Timestamp:
03/21/11 07:57:40 (3 years ago)
Author:
andrewgodwin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode2011

    v18 v19  
    1414 * Russell Keith-Magee (russell@keith-magee.com) -- serialization, ORM improvements, testing 
    1515 * Jannis Leidel (jannis@leidel.info) -- admin, forms, i18n 
     16 * Andrew Godwin (andrew@aeracode.org) -- schema alteration 
    1617 
    1718== Students == 
     
    247248 * #2879 
    248249 * #13873 
     250 
     251=== Schema Alteration === 
     252* '''Complexity:''' Medium 
     253 
     254Django has, for many years, lacked any kind of schema alteration (an idea fundamental to database migrations) in core. Projects like [http://south.aeracode.org South] have become very popular as they fill this gap, and so we're looking to try and bridge the gap and start merging some relevant functionality into Django. 
     255 
     256In particular, schema alteration backends are the first step. Each database has different methods of changing tables, indexes, and constraints; South has code for the five most popular databases, but it's entirely separate from Django. The idea is to merge these backends into the core Django code (and the concept of a Django database backend), supplementing or replacing the "creation" modules with an "alteration" module. 
     257 
     258Once these backends are merged in, the South codebase can be heavily simplified (leaving just features like autodetection and ORM versioning), and other migration frameworks suddenly become a lot easier to write (as now the hard task of working around lack of features in MySQL and SQLite, and dealing with the differing syntaxes of each database is all done already). 
     259 
     260Issues to consider: 
     261 * How would the current creation module in database backends be affected? Would you leave it as-is, or refactor it to use the new alteration code? 
     262 * How will you deal with a lack of features in various backends? South has workarounds for some, but others, such as properly managing indexes, are very difficult. 
     263 * How will you make sure the new API is flexible enough to work with not just South, but other current and future migration frameworks?