| | 250 | |
| | 251 | === Schema Alteration === |
| | 252 | * '''Complexity:''' Medium |
| | 253 | |
| | 254 | Django 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 | |
| | 256 | In 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 | |
| | 258 | Once 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 | |
| | 260 | Issues 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? |