Changes between Version 2 and Version 3 of Tutorial3

04/18/09 10:45:11 (7 years ago)



  • Tutorial3

    v2 v3  
    107 This is bad practice. TBC.... 
     107This is bad practice. Instead, as I described above, you should be making three migrations. Starting with your file in the original state, we should: 
     109 * Add the new `first_name` and `last_name` fields. 
     110 * Run `./ startmigration southdemo add_firstlast_name --auto` - this should make a `` migration. 
     111 * Run `./ startmigration southdemo migrate_names` - this should create `` (which will just be a blank template, since we gave startmigration no options) 
     112 * Remove the `name` field from 
     113 * Run `./ startmigration southdemo remove_name --auto` - this will make ``. 
     115This process can be extended to any kind of migration - do any additions of fields, then create a blank migration in the middle to add your data migration to, then do another removal of fields. This way, in the middle migration, you have access to both the fields you are moving data from and the fields you're moving it to. 
     117You can have a look at the 0003 and 0005 migrations if you wish, but they're reasonably standard schema migrations. We're interested in `` - open it up, and you should see this: 
     121from south.db import db 
     122from django.db import models 
     123from southdemo.models import * 
     125class Migration: 
     127    def forwards(self, orm): 
     128        "Write your forwards migration here" 
     131    def backwards(self, orm): 
     132        "Write your backwards migration here" 
     135    models = { 
     136        ... cut for clarity ... 
     137    } 
     139    complete_apps = ['southdemo'] 
     142When you run `./ startmigration` with only an app name and a migration name, South will create a skeleton template of a migration for you to fill in - it's much more useful than doing that part yourself. 
     144Here, we're interested in data migrations, and so we'll be using the ORM. One thing you should note is that the ORM will '''not work during a dry run''' - if you're using MySQL, all migrations are dry-run before each application, and if you're on another database, you should code to make sure your migrations are portable. You have two ways of making ORM code not run during a dry run: 
     146 * Wrapping the ORM code in an `if not db.dry_run:` block 
     147 * Adding the `no_dry_run = True` statement to the Migration class 
     149We'll do the latter, since our entire migration will be using the ORM, and in general you should be making migrations this way anyway. Adding it to the class, we get this: 
     153from south.db import db 
     154from django.db import models 
     155from southdemo.models import * 
     157class Migration: 
     159    no_dry_run = True 
     161    def forwards(self, orm): 
     162        "Write your forwards migration here" 
     163    ... 
     166Now, we can start writing our migration. You use the fake ORM just like the normal ORM, but prefixing all models with `orm.`. Thus, our loop to copy the names across might look something like this: